Filed Under : 
Nov.15,2007Thu, 15 Nov 2007 17:10:48 GMT
David Chappell
Chappell Associates
David gave a presentation in 2002 at TechEd EMEA comparing REST and SOAP. He made a mistake. He didn’t decry SOAP as devil-worship. The result was a mailboxful of hate from the REST clan. RESTaferians, David calls them. He decided that he’d just ignore the hell out of them. Which he did. For a few years.
But now…
Things are changing. The number of scenarios that REST may be the right choice is increasing.
Personal Experience
I first wrote a REST service back in 1998. It was a classic ASP page that took a query string argument that gave me different Xml data back based on that argument. I used this to fill a "data island" in an IE4 Html DOM. It was kind of cool then, but I could see the technique would have limitations. If I wanted to do more than just read data, how would I enforce what these arguments meant? Wasn’t until 1999 / 2000 that SOAP (which originally stood for Simple Object Access Protocol…) started appearing. I knew it was something more bullet-proof that my knocked-up, poxy ASP page.
REST and WCF
Using GET verbs, Uri notation
Example GET www.barclays.co.uk/Accounts/2
David compares this to a SOAP version of the same request, complete with <Account>2</Account> nodes in the request and SOAP payload excess baggage.
The Principles of REST
Two core principles:
- Everything is accessed through a uniform interface
- All data (resources) is identified with a Uri
Some secondary principles:
- Be stateless
- Be cacheable where possible
RESTful Web Services, by Leonard Richardson and Sam Ruby
WCF Access via REST
Here’s the REST equivalent in as a WCF interface:
[ServiceContract]
Interface Iaccount
{
[OperationContract]
[WebGet]
int GetBalance (string account);
[OperationContract]
[WebInvoke]
int UpdateBalance(string account, int amount);
}
WCF can also support sending binary, RSS, ATOM and JSON over a channel using the WebHttpBinding.
The Semantics of Http Verbs
A closer look shows that REST has got a few complications.
REST typically depends on Http’s verbs
- Primarily PUT, GET, POST and DELETE
The semantics of GET are well defined
- Http GET is idempotent… ?
However, the other Http verbs are not very well defined. And POST is just a big, undefined, black hole. WCF only supports [WebGet] (using Http GET) and [WebInvoke] (which defaults to POST but can be overridden).
Now, David contends that Http GET is idempotent. I take issue with this. Idempotency states that you can invoke an operation multiple times and it does the same thing and it should do this without side effects. Additionally, idempotency implies that each message should get there once and once only. It’s that last point that I don’t think GET can guarantee, thanks to the nature of TCP/IP, the Interweb and replays.
SOAP vs REST
SOAP | REST |
Exposing operations | Exposing data |
High barrier to entry | Low barrier to entry |
RESTful Data Access: Example – Amazon S3
The complete interface to S3 is:
- GET Object
- GET Bucket
- GET Service (your "root directory")
- PUT Object
- PUT Bucket
- DELETE Object
- DELETE Bucket
- HEAD Object (modified date etc)
Problems with REST
In the banking example, you’ve got GET Account, GET (or POST) UpdateBalance. These are all about a single entity. What are you meant to do with TransferFunds()? This implies two resources, and Uri’s can’t stretch to this. Current practice is to have a Uri that represents the operation:
This is potentially a problem for anyone who wants to be religious about REST. Is this against their religion? Exposing an operation as a resource? I’m not sure, neither is David. But I’m not sure it’s important.
Bigger Problems
I have bigger issues with REST:
- Contracts. Can we have one? Please? Not in REST.
- Security infrastructure: no contracts, so this isn’t defined either.
- Reliable transmission: no contracts, so this isn’t defined either.
- Transactions: no contracts, so this isn’t defined either.
- Policy: no contracts, so this isn’t defined either.
- BUT…
- …I still can’t believe HTTP GET is idempotent. At a TCP level, under extreme load conditions, I’ve heard of "ghost" GETs being received multiple times. OK – the mathematical definition of the word idempotent doesn’t include the "exactly one message" refinement, but it’s what the BizTalk guys mean by it, so it’s good enough for me.
In practice, to me this means REST is for data and browser-based mash-ups.
David argues that REST maybe be best for the Internet, but probably not for the enterprise. Problem is, if we’re moving to S plus S or SaaS, isn’t the enterprise moving to the Internet?
Tags : ReST, SOAP, TechEd 2007, Web Services, WS*
