On Mon, May 19, 2008 at 10:14 AM, 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" :). JSON -- not to be confused with JSONP or JSON-RPC -- is just data serialization, same as XML, not more or less RESTful. Data objects not service objects. The thing about JSON is, it's known to alleviate allergic reactions to angle brackets, it's also been used successfully used to create simple, straightforward data representations. Not to dismiss XML, because XML has its own equivalent, often called "XML simple", which shuns namespaces, weird content models, non-data production rules, and anything attribute. If you're just jumping on the JSON bandwagon because "JSON is not XML", then you would be tempted to use features like JSON serialization for your XML data. Now you have two problems! Good luck finding that in-scope namespace on a JSON object. XML as JSON is the bad XML and bad JSON. On the other hand, if you start with a simple abstract model that's not XML, you can map it to XML and/or JSON and benefit from whichever one you use. And while the JSON representation is more efficient, in transmission, storage and parsing, you can't go wrong with either one. If you only do that and still use XML, you're further ahead. The big mistake is doing XML and then pressing the "JSON this!" button (or mapping it to Java or database) believing something good will happen. It won't. Don't design for any representation, and as common sense as it sounds, too many people do just that. BPEL 2.0 is a good example for that, there are some features done a particular way out of concern for what the XML would look like. (And yes, there are some things you can do in JSON that map horribly to XML. Just don't design for any one representation) > > > 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. I wasn't referring to WSDL explicitly or implicitly. One common mistake I see often is the PUT/DELETE litmus test. These two methods do not a RESTful service make, but a lot of people fall into the trap that "just add these two methods and you're gold". A RESTful service can exist purely with GET, and if you only use POST it can still be RESTful (see: Web, the). They should be used, they're just not all there is to REST. You're right that coupling comes from design, not architecture. And both REST and WSDL have that goal, although best wishes and reality are two different things. In reality those are seldom used as they should. I'm not singling out WSDL, REST has the exact same problem when Do Right collides with Do Right Now. The thing is, when you're writing a POJO and waiting for the framework to do the marshaling, you end up with RPC/XML/HTTP. Turning off the SOAP envelope doesn't change the nature of the service. WSDL and REST potentials are irrelevant once you head down the tight coupling road. > > 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. XHR can be used and abused. When you're doing in-place content editing instead of sending a request and updating the same page, you get a more interactive response without changing the nature of the Web. On the other hand, you can squeeze all of Wikipedia into a single URL by fetching resources using XHR, hiding them from the world. Now you get no benefit from either XHR or being on the Web. There is a strong tendency with some UI frameworks to recreate the desktop experience by removing every possible Web feature (and benefit). And to dispel the "XHR is faster" myth. It's not. That used to be the common case with browsers back in the 90's, the dreaded page reload overhead, and when people used tables nested ten levels down for exact positioning. Modern browsers load pages fast enough (even IE), and smart usage of CSS prevents you from burdening the browser. There is a difference between updating an item, best done with XHR, and updating a list of items. But that doesn't require you to violate the Web by cramming all your content into a single URL. And there are nice usage patterns, like auto completion, streaming updates, in-place editing, that contribute to the end-user experience again without coming at the expense of being a Web application. > > 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. That's part of how you achieve decoupling, by putting the service in the driver seat and being in control of the transitions. Assaf > > > 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/ > > -- CTO, Intalio http://www.intalio.com
