Aligning REST with Services
I’ve been meaning to call out a blog from Anne Thomas Manes posted back in March, along with a message in the Yahoo SOA group, as they were finally something that, in my opinion, added some useful information to the ever present REST versus SOAP/WSDL debate. Normally, I stay out of this religious war when it kicks up in the blogs or the Yahoo SOA group, but that’s not to say that I don’t care about it. The fact is, I’m a practicing enterprise architecture in a Fortune 500 company, so I need to be providing guidance when a team comes to me asking about REST versus SOAP/WSDL.
In most of the conversations about REST and SOAP/WSDL, it’s usually a comparison of a single SOAP endpoint (a single URI) to a single REST endpoint (again, a single URI). Invariably, the conversation always wind up being about the uniform interface (GET/PUT/POST/DELETE when using HTTP) versus the non-uniform interface (whatever operations are defined in WSDL) tunneled through the transport (POST when using HTTP) in SOAP. I’ve always felt that this was a bit of an apples and oranges debate because the REST endpoint is exposing a resource, and the SOAP endpoint was exposing a service. When thinking of services in a conceptual, technology independent manner, the mapping to a resource just didn’t seem as straightforward.
The comment that Anne made that helped put things in the right perspective was this:
Service consumers interact with the service through the set of resources it exposes. In other worlds, the resource model is the interface to the service. Each resource exposes a uniform interface (e.g., GET, PUT, POST, and DELETE), but an individual resource is not the complete service.
This made it very clear. If you’re trying to go from a conceptual service model to a design based on REST, an individual service does not equate to a single REST endpoint. Rather, it equates to a collection of REST endpoints that together comprise the resource model associated with that service. In my opinion, the lack of an understanding around this concept is probably also why most of the “REST” services out there really aren’t REST, but rather are XML over HTTP without the WSDL and SOAP envelope. The people involved are still trying to do a single endpoint comparison and not thinking about the resource model as a whole.
Now, I’ll admit that this insight still doesn’t solve the uniform versus non-uniform debate, but I do think that it brings us to the point where a valid comparison of approaches for a particular problem could be taken on within an organization. Thanks Anne!
6 Responses to “Aligning REST with Services”
Leave a Reply
Todd, I too have a different take on this, very similar to yours. REST appears to be quite similar to distributed object paradigm vs a coarse grained, stateless services paradigm. I would say both may have their place under the sun in different contexts.
I agree that Anne’s comments are quite helpful. Modifying them a bit:
Service consumers interact with the service through the set of *operations* it exposes. In other words, the *set of operations form* the interface to the service. Each *operation* exposes a *portion of the interface*, but an individual *operation* is not the complete service.
Operation in this context would be a web service (or could just be plain ol’ XML over HTTP).
Both concetps look an awful lot like methods on objects, don’t they?
One could argue that a service could expose both RESTful and operation interfaces (and a JMS interface, and a file-based interface, and a….).
1. The “wisdom of ganesh” blog has some useful insights on this
2. The REST argument of uniform vs non-uniform interface leaves me cold. To me the REST advocates seem to suggest that you can interact with any service without a contract – the uniform interface is not sufficient for a contract. In the SOAP world there is recognition that you need a contract (WSDL is not sufficient though).
3. Service operations are Verbs. Object methods are verbs. The difference is in a Service there is no concrete object (noun) e.g. a service would transfer money from an account to an account by invoking Transfer(amount, fromid, toid) whereas an OO class would be fromAccount.Transfer(amount, toAccount). The latter exposes the domian model to the client – the former does not.
Peter-
While the last thing I want to do is turn this into a REST versus WS-* debate, as I frankly think both can exist peacefully. To your comments, however, I do think Ganesh’s blog and comments is a good resource. I’ve read it as well. As for the service contract, I’d like to differentiate between the service interface and a service contract. The functional interface is a subset of the service contract, and largely, that’s what WSDL covers. In the REST space, the real debate is whether the payload associated with GET/PUT/POST/DELETE needs to be formally specified. There are mechanisms to do so, but it’s not required in the same way that WSDL does. Beyond the functional interface, a service contract must contain all of the policies that govern the interaction including security, throughput, versions, etc. Neither WS-* nor REST really provide a mechanism for this. As for your comment about verbs, a resource oriented view would argue that all “business” verbs can be represented as GET/PUT/POST/DELETE operations. For your account example, you could certainly argue that a POST to an Account resource could increment or decrement the balance. Again, I’m not trying to take one side or the other, but only to provide information to help others make good decisions. A resource-oriented model is one way of exposing a service, just as one or more SOAP endpoints can do it too.
“a service would transfer money from an account to an account by invoking Transfer(amount, fromid, toid)”
Doesn’t the name of the service (however exposed) expose the domain model? e.g. you can’t call “Transfer” on the “Shipping” service and expect it to move money. The service is the concrete noun.
The whole discussion about exposing domain models is probably worth an article Todd. To my mind there seems to be lots of confusion in this area because ther seem to be 2 (at least models) – the one exposed to the service consumers e.g. account no and the one inside the service e.g. last accessed date. The difference (without saying it is good or bad) between REST and SOA to me is that REST implicitly discloses an external domain model while SOA explicity discloses it.