Loading ...
Sorry, an error occurred while loading the content.

15121Re: [rest-discuss] What do you think about REST being a synonym of Service creation technique?

Expand Messages
  • Stuart Charlton
    Apr 5, 2010
    • 0 Attachment

      To 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.htm

      As 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.


      From: William Martinez Pomares <wmartinez@...>
      To: rest-discuss@yahoogroups.com
      Sent: Wed, March 31, 2010 6:25:48 PM
      Subject: [rest-discuss] What do you think about REST being a synonym of Service creation technique?


      Hello all.
      I got the newsletter from InfoQ this week, and suddenly I noticed something that has been there since long, but till now I didn't realize it.

      In the SOA channel articles and news, there were only one of each. One article about the REST maturity levels, and one news item about REST security. Oh my...
      I thought there was some mistake, that those two items belong to the REST channel, and then I realized that there was no REST channel in InfoQ!

      Then, I had a quick twitter chat with Ryan Sloboyan, Editor from InfoQ. It seems, REST is seen just as a way to create services, opposite to SOAP / WS-* lineage. Ryan told me there is always a possibility to create a REST only channel, but he thinks that will be a narrow one, with not so many readers. The expectation is then REST readers will come just to learn how to create easy services nos using SOAP.

      Now, Jack Vaughan from SearchSOA was in a fireside chat with me, at the Java Symposium from TheServerSide, where I was to talk about REST apis, and their real meaning. He told me his idea of REST was similar to that one of the new way of doing services for SOA. We got a full room, and I asked if someone as ever read Roy's dissertation. None, and some with faces of "who the hell is that Roy guy?". The question of how many thought REST was a new way of doing services yield to several hands up. Also the one about REST as an HTTP driven RPC.

      So, all in all, it seems the idea of REST as an Easy Services Creation technique is strong, even influenced in the InfoQ categorization of articles and news.

      I know some of you do post on InfoQ, and are even editors.
      What are your thoughts? Do you think it is good to keep that idea?
      Do you think that is actually the idea?
      What do you think of posting REST as an architectural style?

      I want to hear your opinions, since I feel that would be an interesting discussion.

      William Martinez Pomares.

      Looking for the perfect gift? Give the gift of Flickr!
    • Show all 18 messages in this topic