Thomas, also great comments, but I’d like to address the ‘limited to GET, POST…’ angle. You pretty much nailed it when you described how it changes your thinking about the architecture. So in that way, don’t see the HTTP verbs as being limited, see the interface as being uniform, consistent, and predictable. You can have as many nouns — resources, URLs, *things* — as you desire, and the way you manipulate those things is the same no matter what. This approach gives many advantages, not least in being able to properly use application firewalls to see what the intent of an incoming call is.

Contrast this with SOAP, where there is no consistency, no uniformity. With REST you get the verb, and the intention, in the header; you don’t need to look into the body. And that verb predictable. With SOAP, you not only have to look into the body to find the method name, but also have to figure out what it’s going to do (Only read? Update? Create? etc). The inconsistency can even be seen in your example list of SOAP calls (I know it’s only an example, but nonetheless…).

Anyway, I totally agree with the fact that your perception changes.

dj

1) SOAP is pretty slow compared to REST. So if you want to build a client server application and need really fast response times I would recommend REST since the SOAP stack is quite heavy.

2) For me the biggest thing about REST vs. SOAP is how it changes my thinking about the architecture of the application. I like to call it Verbs (SOAP) vs. Nouns (REST). In REST the set of verbs are fixed. If you decide to use REST via http you are limited to GET, POST, PUT and DELETE. Every resource which you expose via REST only has those set of verbs. SOAP on the other side offers the flexibility to bundle a couple of verbs. Let me give an example. Consider a scenario in which a user has to log into an application.

A possible REST solution would have one resource called session. You can then map the http verbs to the resource:

- GET /session -> Return whether the user is logged in or not
- POST /session -> Creates a new session for a given user
- DELETE /session -> Logs out the user
- PUT /session -> Update the session with some new information

A possible SOAP solution could be a bundle of services:

- LogInUser()
- LogOutUser()
- IsUserLoggedIn()
- UpdateUserInformation

It is quite interesting how your perception of a domain changes once you move from verbs to nouns.

The confusion comes because people think of HTTP as a transport protocol – when in fact it is an application level protocol. By itself, HTTP is not sufficient; as DJ already implied – you also need an associated “media type” (such as text/html).

The challenge for those who want to use HTTP for server-to-server communication in a true RESTful manner, is that you need to find the appropriate media-type to play the same role that HTML does for browser-to-server communication. Protocols like Atom and Atompub get you some of the way. But even a combination of HTTP + Atom + Atompub is not sufficient. Of course, most of us don’t want to have to define our own media type for every single application we want to expose this way. The way Google handle this with their GData APIs may be a reasonable compromise (is not strictly RESTful – but it’s probably close enough to still capture most of the benefits of REST).

BTW – Dan’s explanation of the extreme late binding nature of RESTful services was great. Fielding called this “Hypertext as the engine of application state”. This can be a difficult thing for developers, who are more used to RPC style integration, to get their heads around. If you find people describing their Web APIs as “REST based” – but you find no (or very few) URLs are returned in any response body – then please dismiss the “REST” label in this case as pure marketing.