Hi all, First of all I apologize for my late reply. Past few days I was busy with new key manager implementation for Apache Rampart/C and some bug fixes.
At the beginning of this project I planned to implement a Web Services and AJAX based management console(Because I prefer WS-* than REST). Management and Monitoring API will be implemented as Web Services and AJAX requests used to update the UI. But now I feel that we have more things to when implementing web based management console. I think that using JSON objects will increase the responsiveness of the Web UI, because JavaScript understand JSON than XML(XML APIs are different from browser to browser). If we use Atom API, I think we can implement a API like Google Data API :). Frankly, I don't have any experience with pros and cons of these technologies. I think it's better we can first define the API in whatever the way (Web Services or REST) and then go for the UI. While defining API and implement it we can give a very basic level of Management interface by using currently available Web Service based API. Then we can identify the issues with the WS-* based API and also can discover more and more requirements. Please feel free to comment on this. Thanks Milinda On Thu, May 15, 2008 at 12:14 PM, Assaf Arkin <[EMAIL PROTECTED]> wrote: > On Wed, May 14, 2008 at 3:16 PM, Tammo van Lessen <[EMAIL PROTECTED]> > wrote: > > > Hi Assaf, > > > > > > Assaf Arkin wrote: > > > >> Here's four things I learned from trying to do that, which just didn't > >> work. > >> There's more, but I think these four would be enough: > >> > >> 1. Quite early into the development you realize the UI and API are > >> optimized for different tasks, they quickly diverge and you end up with > >> components that have UI and API functionality, but they don't always > >> overlap. It seems like a good idea -- reuse -- but the resulting code > is > >> unfortunately harder to maintain than keeping the two separate. > >> > >> 2. If you're coming up with a new version of the API, it's generally a > >> good > >> idea to place it elsewhere than the original version, so each version > gets > >> its own resources. If you're coming up with a new version of the UI, > it's > >> generally a good idea to place it where the old version was, preserving > as > >> many resources as possible. > >> > >> 3. The API response to creating a new resource is 201, the UI response > is > >> 303, unless you want some JavaScript code back to render the change, in > >> which case it would be 200. The URL for an API update would point to > the > >> resource you're changing (with a PUT), but the URL for a UI update would > >> point to a form which will then be used to make the update. > >> > >> 4. If you can request the same resource as HTML or JSON, you can > imagine > >> using one to render a full page, and the other to just pull new data and > >> update existing page in-place. Except browsers don't handle Vary, so > the > >> second request would bring the cached HTML copy instead of the expected > >> JSON. > >> > > > > Thanks, point taken. That it very interesting! Sounds like theory and > > practice aren't aligned here as well :) I should spend more time with > > playing with code... > > > I'm working now on a task manager for ODE, it's a sandbox project, if you > want to have a look at it. Great place to experiment with some of these > issues, specifically because it serves both end-users and workflows, which > have different requirements. And also because it will be pulled by the > forces of too-much AJAX on one side, and fondness for EJB/HTTP on the other > side. > > Assaf > > > > Cheers, > > Tammo > > > -- http://mpathirage.com http://wso2.org "Oxygen for Web Service Developers" http://wsaxc.blogspot.com "Web Services With Axis2/C"
