15121Re: [rest-discuss] What do you think about REST being a synonym of Service creation technique?
- Apr 5 1:38 PMTo answer your questions:- I don't think it's a good idea to equate REST with "easy services creation". I'd be more inclined if people equated specifics like "Atom/Atompub" or "OData" with "easy DATA services creation", personally.Enterprises should keep building SOAP web services if they are happy with RPC or messaging systems, and can force their vendors to make it "easier".- The actual *idea* for REST is not "easy services creation" -- it is "large-scale information sharing & manipulation". It is for interoperability at very-large scale, a "system of systems" architecture: http://www.infoed.com/Open/PAPERS/systems.htmAs such, it is not necessarily "easy" to apply to all situations, it requires knowledge & experience (like most things).- Explaining REST as an architectural style works for some, but more likely there's also a need to explain REST in the context of SOA's verbiage (e.g. governance, interoperability, loose coupling, contracts).- Probably there will need to be more mainstream books and tooling for the lay-developer, that gets into *how* the development experience is different. Unfortunately, that's a moving target.Some comments:The general trend among the SOA crowd has been to equate REST with "Plain XML over HTTP", and to this day, it remains the popular understanding in most enterprises. Most don't really understand the key features (URIs and hyperlinks), though I have had some exposure that some are beginning to explore deeper once they dig into Atom & Atompub.The problem with using REST as "easy services creation", is that you may be committing greater sins to your maintainability than using WSDL & SOAP if you don't use HTTP & URIs properly (e.g. performing state changes with GET, using a single URI as an "endpoint", including application-specific methods in the XML body, etc. ) At least with SOAP & WSDL there is tooling & infrastructure for governing the little interoperability you do get with it. With REST, the tooling & written literature is still very young, and the vast majority of developers are never going to read Roy's thesis.Part of the problem is that the Web Architecture and REST are very different ways to think about distributed systems design, whereas SOAP-style SOA services are an evolutionary descendent of (depending who you talk to) distributed objects ala CORBA/COM, or message queues ala MQ or TIBCO, which have a much longer history in some people's minds.CheersStu
Looking for the perfect gift? Give the gift of Flickr!
- << Previous post in topic Next post in topic >>