InfoQ Article - Give it a REST: Mark Baker on Web Services

Posted by Stefan Tilkov on Aug 28, 2006

Sections

Architecture & Design,

Enterprise Architecture

Topics

REST ,

Web Services ,

SOA

Tags

UDDI ,

WSDL

Mark Baker is well-known in the SOA and Web services community because of his continuous efforts to promote an architectural style called REST (Respresentational State Transfer), criticizing many of the standards and specifications as being ignorant of what made and continues to make the Web successful. InfoQ's Stefan Tilkov had the chance to talk to Mark about REST principles, its benefits, and the relationship to Web services.

Read Give it a REST: Mark Baker on Web Services.

1. Back to top

   REST and SOA

   by Neil Belford

   Very interesting Mark, but aside from the detail REST which is excellent and informative, you seem to be perpetuating the standard confusion in here about what SOA is about.
   
   RESTful services are still services. I agree in the main with your comments about Web-Services, and have never been a fan of SOAP, but SOA is not about Web-Services, it is about realising a documented set of re-useable services on an ESB.
   
   Probably the best way of achieving this is to think about what your ESB needs to look like.
   - It will need fine grained secure, reliable messaging, which neither WS-Anything nor REST is good for, but JMS or other MOM products are,
   - It will need REST for the reasons you describe above,
   - It will need Web-Services for interoperability
   - It will need a control bus.
   - It will need a mechanism for identifying and choreographing these services.
   
   So please, when you use the term SOA can you articulate what you mean by that term. If you mean SOA IS Web-Services then you have to find a different term to describe what (certain proprietary vendors aside) the rest of us mean by SOA.
   
   SOA could just as easily be SA, only software naming history is on the side of SOA, nonetheless we are talking about Services Architecture, not Web-Services Architecture.
   
   This is about architecture and not products, but if you need tools in this space, we at Base2Services are finding JBoss JEMS pretty compelling.
   
   
   Regards
   
   Neil Belford

   Reply

2. Back to top

   Re: REST and SOA

   by Mark Baker

   Interesting response Neil, I can't say I've seen one quite like it before. I guess that's what exposure outside my typical clique gives me.
   
   I use the term "SOA" as I believe most people use it - as a name for an architectural style, an abstract description of an architecture. In this case, a name for a style which espouses exposing data and functionality over a network via a variety of interfaces.
   
   I try to avoid the term "ESB" because I still don't know what one is; I've seen wildly different products described as one, so from my POV is meaningless.
   
   I don't believe that SOA = Web services, though I'm lead to believe that Web services follow SOA principles (at least I haven't heard anybody large outcry that they're not). I agree with this part of one of your statements; "SOA is not about Web-Services, it is about realising a documented set of re-useable services". I left off the ESB bit for the reasons mentioned above.
   
   
   As for your five points about what's needed, I'm unclear about;
   - why JMS/MOM provides the kind of messaging you want, but REST or WS-* do not (or can't)
   - why "it will need Web-Services for interoperability"; on the Web, HTTP does a good job at providing interoperability
   - I don't know what a control bus means in this context
   - and for choreography, REST has hypermedia (or maybe that's orchestration - I can't get those straight).

   Reply

3. Back to top

   Re: REST and SOA

   by Eric Roch

   I wrote a post on this topic. Here's an excerpt...
   
   REST and WS can both be used to expose and consume services. The REST argument often implies that you have a choice, i.e. that you can dictate to your consumers that they will use REST. Or, that a service you need to consume will exist in a REST form. This usually is not the case...
   
   blogs.ittoolbox.com/eai/business/archives/the-r...
   
   The prior post also talked about building mutiple interfaces - e.g. REST and WS.

   Reply

4. Back to top

   SOA aims to become REST but will usually fall short

   by Stuart Charlton

   I'll put my naive hat on:
   
   1. REST is unpopular among many architects not because people don't agree with the the principles, but because they don't like HTTP. They love their MOM. They love the flexibility of many message exchange patterns available. They want to standardize reliability & security across classic distributed systems AND services-oriented systems. They tend to look at problems "application first", "database first", or "objects first", not "network first". HTTP's statelessness is something to be worked around, with cookies & sessions, because they haven't been exposed to the principles behind its design in a way they can understand.
   
   2. SOA doesn't preclude REST, in my opinion. I would liken SOA as a style that has a weaker set of uniform interface constraints. It still requires self-descriptive messages and also requires maniupulation of resources through messages. It doesn't emphasize universal indentifiers or hypermedia as the engine of state. Most advanced discussions of SOA out there emphasize the need for governed, if not uniform, interfaces and media types. This is unacceptable to many because uniformity requires a political investment that many can not or will not make. SOA is a style for people that will try to become more governed, aiming for uniformity, even if they fall short. REST is the ideal.
   
   3. I think most architects will eventually recognize the biggest architectural challenge to SOA coming soon is the lack of uniform identifiers. If I have two services with their own sets of primary keys, how do they match up? How do I dereference them? Oops. URI's are a solid way forwards here but people seem to undervalue them and underuse them. SOAP/WS-* do not help matters. WS-Transfer kinda does.
   
   4. The biggest challenge and most controversial constraint that precludes many SOA's from becoming RESTified is the role of hypermedia as the engine application state. Classic distributed systems, the application, or orchestration service, etc. is in control of all shared state. It's fully encapsulated. REST and the web says: "View Source". It keeps encapsulation for "resources" (which can be anything) but asks for openly viewable, standard representations, metadata, and methods for manipulating them.
   
   Many in positions of power really do not like the web, for a variety of social, technical, and economic reasons. They may use web technologies used for cost avoidance & productivity, but want their systems to be as fat-client-like as possible. Pushing web-style inside a corporation can at times be a career limiting move. I do not know if this is temporary or permanent; I will observe that power tends to endure until a major crisis.

   Reply

• Older >