Right at the point when everyone considered the debate around REST to be over, there has been a new wave of REST publications. As Mark Little observed:
It's fair to say that the mere mention of the word REST causes polarization in people...
Following this trend, a new article by Ronald Schmelzer tells the story of why and how he moved from Web Services to REST.
According to Schmelzer and, consequently, ZapThink:
Representational State Transfer, commonly known as REST, is a style of distributed software architecture that offers an alternative to the commonly accepted XML-based Web Services as a means for system-to-system interaction... when I needed to implement the Services I had already determined were necessary, I faced a choice: use Web Services or REST-based styles as the means to interact with the Services. For the reasons I outline below, REST was a clear winner for my particular use case.
This statement by itself is an interesting one, because it directly contradicts one in a Dhananjay Nene’ earlier : post
Service orientation is neither essential for, nor is it the intention of REST. Not only is REST not service oriented, service orientation is irrelevant for REST... REST does not attempt to be service oriented. That’s because it does not view the process as a sequence of tasks to be performed. It views it as a sequence of resources under modification. To put it differently, it views the process as a set of actors who exchange resources (or documents for better visualization) and carry out activities based upon receipt of such resources.
So what Schmelzer is really talking about does not really seems to be REST, but rather what is often referred to as REST Web Service - an approach for using REST technologies to build SOA. Although commonly referred to as REST, this approach has nothing to do with true REST and is similar to POX (plain old XML over HTTP), with the difference being that in addition to XML, it supports multiple other data marshalling types ranging from JavaScript Object Notation (JSON) to ATOM to binary blobs and leverages additional HTTP methods, compared to POX, which is typically based on GET and PUT.
Schmelzer continues by saying that he:
... ended up using REST for a number of reasons, but the primary one is simplicity... REST is simpler to use and understand than Web Services. Development with REST is easier and quicker... and this is the reason why many of the most-used web APIs are REST-based... But even more than the simplicity, I appreciated the elegance of the REST approach. The basic operation and scalability of the Web has proven the underlying premise of the fundamental REST approach. HTTP operations are standardized, widely accepted, well understood, and operate consistently..
Which is a typical set of REST advantages that can be found in every REST publication, but one would expect more details from such reputable analyst company as ZapThink.
Returning back to the architectural issues, Schmelzer writes:
So, how did I meld the fundamental tenets of SOA with a REST-based implementation approach?... REST is an architectural style, not an implementation, and that the Web and the use of the HTTP protocol happens to be designed under such style.
Unfortunately Schmelzer never answered this question. He goes on talking about using the XMPP protocol, but does not really explain how two architectural styles - ROA and SOA - can come together.
Schmelzer finishes his article by saying:
I don’t believe that REST or Web Services is something upon which to take a religious stance. That being said, for the past decade or so, dogmatic vendors, developers, and enterprise architects have reinforced the notion that to do SOA properly, you must use Web Services... SOA can be done well in practice without using Web Services. The conversation about SOA is a conversation about architecture - everything that we’ve talked about over the past decade applies just as equally when the Services are implemented using REST or Web Services on top of any protocol, infrastructure, or data schema. While good enterprise architects do their work at the architecture level of abstraction, the implementation details are left to those who are most concerned with putting the principles of SOA into practice.
And so, the discussion about REST being better than Web Services continues, but there is still no evidence whether true REST should be considered as a foundation for SOA.
Community comments
Main Issue: Is REST really for Services?
by William Martinez,
Wrong question?
by Dave Nicolette,
Re: Wrong question?
by William Martinez,
Re: Wrong question?
by Boris Lublinsky,
Resource-Orientation is not REST
by Dave Duggal,
Re: Resource-Orientation is not REST
by Boris Lublinsky,
Re: Resource-Orientation is not REST
by William Martinez,
Re: Resource-Orientation is not REST
by Dave Duggal,
Re: Resource-Orientation is not REST
by Boris Lublinsky,
Re: Resource-Orientation is not REST
by Dave Duggal,
Re: Resource-Orientation is not REST
by Boris Lublinsky,
Re: Resource-Orientation is not REST
by Dave Duggal,
Re: Resource-Orientation is not REST
by Boris Lublinsky,
Re: Resource-Orientation is not REST
by Dave Duggal,
Main Issue: Is REST really for Services?
by William Martinez,
Your message is awaiting moderation. Thank you for participating in the discussion.
Interesting analysis. I do agree with @dnene, REST is not a web service implementation technology. It was born to solve other issues. And using it for SOA may have some impedance mismatch (video in Spanish).
Actually, following the analysis of the video, that evidence Boris is looking for may be found by measuring the effectiveness of implementations in terms of quality attributes, far more professional than just saying it is "easier".
Still, we can actually use a combination. That is in two ways: Using a REST system as a service and using a web service as a resource for REST.
REST as Special Service construction architecture is suitable for:
1. Large distributed data
2. Hypermedia related or Insensible to format transformation.
3. Relaxed Security
4. Independent evolution requirement
5. Non processing intensive
6. Non sensitive to performance hits, cacheable
while, a Services as a Resource can be achieved if we:
1. Define a service has an ID just as a Resource
2. A GET to that resource will return the services description doc (SDC).
3. SDC contains links with flow and document semantic rules
4. So, the Service is usable in any RESTful Interaction.
Still, both will have impedance mismatch, we just have to level the impact.
William Martinez Pomares.
Wrong question?
by Dave Nicolette,
Your message is awaiting moderation. Thank you for participating in the discussion.
Maybe it would be useful to consider whether a RESTful approach can solve the same problems as SOA addresses in a different (simpler?) way than Web Services, rather than just trying to shoehorn REST into a Web Services mindset.
Re: Wrong question?
by William Martinez,
Your message is awaiting moderation. Thank you for participating in the discussion.
Good Point Dave.
Still, I tend to think that the problems SOA addresses are different than the ones REST does. They are different types of distributed applications. If you have a problem that is better suited for SOA, trying to make it fit into REST may be like looking for the keys at the street lamp instead of your front door simply because there is more light over here. I call that Wagging the Dog.
Regards.
William Martinez Pomares.
Re: Wrong question?
by Boris Lublinsky,
Your message is awaiting moderation. Thank you for participating in the discussion.
William,
I personally share your opinion.
REST is all about resources, while SOA is all about services. Those are two very different things which as you said are suited for different purposes. Both REST and SOA are different architecture styles and you will end up with two very different implementation, depending on the style of your choosing
Resource-Orientation is not REST
by Dave Duggal,
Your message is awaiting moderation. Thank you for participating in the discussion.
REST and SOA are two very different intentional architectural styles that are designed for fundamentally different purposes, the fuss often seems to be more a tempest in a teapot than anything material.
REST is a Network Architecture for Ultra-Large Systems based on client-driven applications. It is document or information-centric with functions performed by Client.
SOA is a distributed systems architecture that is server-driven. It is functional and data is a second-class citizen.
"Apps" created in these two styles have little in common, so there is a practical engineering divide re: best tool for the job.
RESTful Services or RESTful APIs don't equate to a REST Architecture, no more than 'Web'-services have a relationship to the Architecture of the Web it references.
What I don't see in these arguments is any real exploration of Resource-Oriented Architectures and the power of a third-style that uses Resources as its artifact, but is not dogmatically bound to all REST constraints. Perhaps the middle road is always lost to polarized debates.
Re: Resource-Orientation is not REST
by Boris Lublinsky,
Your message is awaiting moderation. Thank you for participating in the discussion.
Dave,
Now I have to ask the question. What are RESTful Services? And how are they different from POX?
Re: Resource-Orientation is not REST
by William Martinez,
Your message is awaiting moderation. Thank you for participating in the discussion.
Hi Boris, Hi Dave.
Dave is referring to ROA, the third option, something that is not REST but still focuses on resources. I still need to get clear in the same issue Boris asks, a clear definition of RESTFul services that are not as fuzzy as services following the REST constrains.
In any case, as Roy commented in some lost comment I did made long ago, we do not need to be complaint with all REST constrains. REST is actually a set of styles carefully chosen to work together. We may need the benefit from a couple of them, and may not need the others. So, we can use them, no need the full REST, but as Roy says, you cannot called it REST either.
We may need to stop talking about REST and SOA and start talking about alternatives, suitable for the job at hand.
William Martinez Pomares.
Re: Resource-Orientation is not REST
by Dave Duggal,
Your message is awaiting moderation. Thank you for participating in the discussion.
Hi Boris,
The references to RESTful Services or RESTful APIs was primarily to highlight a general looseness in usage, and in particular, the usage of a capability to 'certify' an architecture's web-credentials from a marketing perspective.
As I mentioned, we use Resource-Orientation, we don't claim to be REST (or SOA for that matter). In our Framework we use the term RESTful Service to describe an external endpoint that is represented in our system by a Resource (an XML file), which defines the 'semantic' for interoperability with that Service. A RESTfully encapsulated system can be explained similarly.
Dave
Re: Resource-Orientation is not REST
by Boris Lublinsky,
Your message is awaiting moderation. Thank you for participating in the discussion.
Dave, William,
This is the issue the way I see it. In the case of SOA there is a clear delineation - SOA is an architectural style; Web Services is a communication framework technology. I ca happily Build SOA systems without usage of Web Service and can happily use Web Services in non SOA systems.
When it comes to REST, there is no such separation - technology is tightly coupled to architecture.
This is the reason why when I hear REST services, the combination of two words does not sound right to me. I understand people using these two words together for marketing purposes, but for the technical reasons?
Besides, what you Dave is describing, sounds surprisingly similar to a service Registry, storing WSDL definitions for different endpoints
Re: Resource-Orientation is not REST
by Dave Duggal,
Your message is awaiting moderation. Thank you for participating in the discussion.
Hi Boris,
I agree - a 'REST Service' conflates a specific Architectural style with a technology that is not part of the style. To the extent a pure REST interaction produces a business function via a uniform interface (generally HTTP, not limited to) it's not helpful to describe those as services.
I used the term 'RESTful' Service to indicate a REST-like handling (Resource-based wrapper) of a conventional Service (uppercase 'S', the technology). For us it facilitates interoperability between Architectures - I think my usage described above is somewhat normative. The approach provides a value akin to a Service registry except that there is no separate registry, we have one virtualization layer of distributed Resources, that's it - that a Resource happens to represent an external service is non-consequential to our System.
The danger is when folks loosely use words in a technical setting that are specific terms of art without qualifying 'like a...'
As to Resources being coupled to REST style, I'm not sure that's true. A Resource is just any information addressed by a URI, it can be exploited by any Architecture. We use Resources, but we don't follow all REST constraints, per Fielding (as William pointed out) we are Resource-Oriented, but not REST.
Here's where it gets interesting, RO and SO are both movements that are a response to limitations of dogmatic REST and SOA respectively. SO and RO point towards a common center, where dogma matters less than properties for practical purpose.
Our Resource-Oriented Architecture effects a service (lower case 's', business function) from Resources using behavioral protocols and an agent - we do this without SOAP, WSDL or UDDI. In this way, we induce read-write-execute for a functional web.
Dave
Re: Resource-Orientation is not REST
by Boris Lublinsky,
Your message is awaiting moderation. Thank you for participating in the discussion.
Dave,
I think it goes much deeper then that. I think that a main difference between SOA and ROA (or SO/RO as you prefer to call them) is in your decomposition approaches.
In the case of SO you decompose into a set of reusable actions (verbs)where a data for the action execution is supplied in the invocation message.
In the case of RO you decompose on the data level and the majority of the data is in the resource itself.
Re: Resource-Orientation is not REST
by Dave Duggal,
Your message is awaiting moderation. Thank you for participating in the discussion.
Bruce,
Decomposition approach is where we can start talking objectively about optimal/suboptimal for purpose. I didn't go there as I wanted to avoid a religious war ;)
Functional decomposition is a good approach for distributed interoperability, but not everything is a function. Data as a second-class citizen sets up impedance mismatch that reduces expressiveness of the architecture. The SOA style promotes re-use of generic services, but re-use has never met vendor claims. Service granularity is either too generic for varied business needs or too specialized for widespread re-use. Distributed component based execution also introduces indirection and latency as patterns stack up on patterns. This makes anything dynamic 'expensive'.
REST has specific constraints that limit its practical use for enterprise applications, however, from a decomposition perspective everything can be decomposed to data, including code/programs/functions/rules even Services and Legacy systems as I described above. Resources are any information addressable by a URI. Resources are also better for transformation.
Resource-Orientation provides an optimal environment for mashing up relationships and injecting dependencies at run-time, which is why we can dynamically generate service boundaries for richer business apps.
Re: Resource-Orientation is not REST
by Boris Lublinsky,
Your message is awaiting moderation. Thank you for participating in the discussion.
Dave,
I am not trying to discuss which decomposition approach is better. Both are useful in different cases.
My only point was that they are sufficiently different. You can build a working system using both, but... those will be two very different systems
Re: Resource-Orientation is not REST
by Dave Duggal,
Your message is awaiting moderation. Thank you for participating in the discussion.
Decomposition approach is a good way to consider suitability for purpose. I didn't say 'better', but Architectural choices, as with Development tools, can be more or less optimal for a purpose. Weighing these trade-offs is important; there is a lot of accidental architecture out there.