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

15135Re: What do you think about REST being a synonym of Service creation technique?

Expand Messages
  • William Martinez Pomares
    Apr 6 6:21 AM
    • 0 Attachment
      Hello Stuart.
      Thanks, very complete answers!.

      1. Actually, I don't think either that REST="easy services creation" idea is good, so I'm with you totally. On the contrary, I feel that idea is carving into developers that jump right into "REST" after reading a couple of blogs, and then find out they didn't got REST at all.

      2. Making SOAP Services (Read RPC) is the easiest thing to do. Making them work together is another issue. Making real Web Services (using documents and messaging) is a pain in your little finger since there is not top down approach. Your system may be a fit for WSA, or a fit for SOA (slightly different benefits and requirements), but the implementation side is failing terribly.

      3. The "actual" idea is not the "popular" idea, right? It is the Idea we need to pursue to become popular. Agree totally that is not the easy one to understand, apply and identify as the best to use.

      4. "SOA's verbiage" you mention is not actually from SOA, but sadly those concepts were made popular by SOA and from there people get confused. Governance and contracts came from the business world, the first one to increase the interest of business people to invest on the technology (yep, a worm to catch the fish) and the second one came from WSA. Interoperability and loose coupling came from OO world, and thus created the illusion that SOA was a OO system in disguise. Actually, many SOA implementations out there are Distributed OO in disguise. A pity, since Pure SOA has nothing to do with it.

      5. Totally agree with your point to maintainability! We need to make that clear and loud. (Just don't call them sinners).

      6. Same, I agree about the descendants part. Still, the SOA idea is different from Implementation. I'll be naive enough to think the SOA and Services idea were born pure, and when implementation started, tool vendors took what they have at that time (SOAP as the next Corba/Dcom generation, and Message queues) and did some rebranding to get to sell SOA tools! So, I still think we can save the pure ideals of SOA (but not with REST, which is a different kind of beast).

      Now, question, what should we do about it?

      Thanks again, Stuart.

      Cheers!

      William Martinez

      --- In rest-discuss@yahoogroups.com, Stuart Charlton <stuartcharlton@...> wrote:
      >
      >
      >
      > 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.
      >
      > Cheers
      > Stu
      >
      >
      >
      >
      >
      > ________________________________
      > 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.
      >
      >
      >
      >
      >
      > __________________________________________________________________
      > Connect with friends from any web browser - no download required. Try the new Yahoo! Canada Messenger for the Web BETA at http://ca.messenger.yahoo.com/webmessengerpromo.php
      >
    • Show all 18 messages in this topic