Sanjiva, I am confused by your comments. Where in Assaf's post did he mention that WSDL cannot be torn out without breaking the client?
Additionally, I can't understand how Assaf's comment about JSON implies its superiority over XML in RESTful architectures. The message I inferred was: Good solutions are a result of precient design that isn't a prisoner of the tools & frameworks. Seems like a perfectly legitimate premise and one I agree with. God only knows why this became a REST vs. WS-* debate, I think that's precisely what he was trying to avoid with the last sentence of his post! Cheers, Zubin. On 5/19/08, Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote: > > Assaf Arkin wrote: > >> Besides the management console, we have three other ongoing projects in >> Ode. >> One adds HTTP binding and REST support to the engine, so you can use Ode >> to >> interact with and develop services conforming to the Web architecture. >> You >> could build a JavaScript front-end to interact with the process, or have >> the >> process tap into services that don't pay the WS-* tax. In certain cases, >> > > Ah, a true fan of WS-* ;-). > > The best way to start is to start small, but always keep an eye on the >> target. You don't have to do JSON in the first release, just XML may be >> good enough, but watch out that your data model can map nicely to either >> one, because XML magically mapped to JSON has neither the benefit of being >> XML nor the benefit of being JSON. >> > > JSON or XML or plain text or whatever has absolutely no impact on whether a > design is RESTful or not. You appear to be suggesting that somehow JSON is > more RESTful than XML .. which really is somewhat ironic given the "O" in > JSON stands for "object" :). > > You don't have to do any PUT or DELETE, >> maybe your first service is just a lot of queries, but watch out that >> you're >> not building something that can never accommodate for that. A good idea >> is >> to look at REST as an interface and see if you can tear out and replace >> the >> implementation without breaking all your clients: are the resources you're >> using well thought out, or could they only be implemented by FooBar? >> > > Sorry but this is hogwash. I don't disagree with most of your post but to > suggest that a service interface described in WSDL cannot be torn out and > replaced without breaking clients is silly. That's *exactly* what WSDL was > designed for. REST nor any other approach to architecture automatically > guarantees proper decoupling; that requires careful design. > > There's a lot of fascination with XHR, which can be put to good use to >> enhance a service. But there are also ways to use XHR to hide the service >> from the world. Can I bookmark this page and return to it later? Can I >> IM >> this link to someone else so they can look at it? Can I subscribe to >> changes from my feed reader or pull this into my calendar? Can I have a >> widget that shows this content on my desktop? The temptation to build >> desktop-like applications that are closed off the Web is there, but best >> ignored. >> > > XHR is useful and necessary to make your interface more interactive. > Otherwise you have to load a brand new entire page everytime something is > done .. which most people consider 90s style Web UI design rather than > modern design. Obviously YMMV. > > If you want the benefits of REST, always think how to keep clients >> decoupled >> from servers, and which principles - not tools - will get you there. >> > > To get the benefits of REST you have to go beyond decoupling- you have to > design a set of interlinked resources that are easily navigable by clients. > I agree that tools cannot do that. > > Sanjiva. > -- > Sanjiva Weerawarana, Ph.D. > Founder & Director; Lanka Software Foundation; http://www.opensource.lk/ > Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/ > Member; Apache Software Foundation; http://www.apache.org/ > Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ > >
