mnot’s blog

Design depends largely on constraints.” — Charles Eames

Monday, 7 November 2005

REST vs..?

More and more people are getting turned on to the advantages of using REST as a higher-level abstraction for networked applications, often comparing it favourably to SOAP and Web services.

However, as many have pointed out, this is a bad comparison to make; REST is an architectural style, while SOAP is a protocol. So, what should be compared?

When this question comes up, I’ve found it helpful to draw a table with different architectural styles in the columns, and protocols that implement them in the rows, filling in the cells with examples of each combination;

(e.g., SOAP)

There are, of course, many more protocols and architectural styles to choose from, but a few observations follow from this table already.

First of all, it’s clear that, with a bit of work, you can get any of the listed architectural styles with both SOAP and HTTP. SOAP can do this because its native architectural style, SOA, is a very low-level one (often summed up as “messaging is good”), so it’s possible to build up other architectural styles just by adding to it. Conversely, HTTP is a higher-level abstraction, formed around stateful resources, rather than messages. That said, it’s possible to get the other architectural styles with it by willingfully constraining its use.

Because of this, it’s easy to mischaracterise what architectural style is in use; while what protocol you’re using is obvious, architectural style is a more ephemeral thing. In particular, lots of “Web 2.0” applications say they expose “RESTful” interfaces, when in fact they’re just doing POST-only HTTP, thinking they automatically get the benefits of REST just because they use HTTP.

Apples to Apples

With this in mind, it’s more reasonable to compare protocols that implement a particular architectural style (I’ll leave the comparison of architectural styles to other blog entries).

When doing so, notice that REST is native in HTTP, and SOAP is native for SOA. Intuitively, I’d rather use HTTP if my chosen architectural style were REST, especially considering how widely deployed and provably interoperable it is. I can choose any number of off-the-shelf, commercial or Open Source intermediaries, caches and libraries to take advantage of REST in HTTP, but the same is not true of REST in SOAP. Especially when we seem to get a new GET-in-SOAP every time we turn a corner.

Filed under: Protocol Design Web Web Services


Mark Baker said:

Fun post!

For your table, I think you're missing an option; RESTful SOAP. Both SOAP 1.1 and SOAP 1.2 can be used largely RESTfully; just don't stick an operation in the SOAP envelope, and instead use that provided by HTTP. The bad news is that it doesn't fit well into your table because you're using SOAP and HTTP together, with HTTP as a transfer protocol and SOAP as a protocol extension protocol.

P.S. you doubled up on "to compare".

Monday, November 7 2005 at 7:15 AM +10:00

Yaron said:

I'm a bit confused by your definitions. You indicate that to use SOA with HTTP you have to use tunneling. But I'm not sure what that means. What about SOA makes it non-native to HTTP? I suspect the problem is that I don't understand your definition of SOA.

Also, as for REST, why is HTTP necessarily RESTfull? After all, you can add arbitrary methods and so use HTTP in ways that aren't RESTfull.

Also why isn't REST just a subset of SOA? Seeing your definitions of what REST and SOA are and why the former isn't a subset of the later would be helpful.


Monday, November 7 2005 at 9:56 AM +10:00

Mark Nottingham said:

Mark —

“to compare” — fixed, thanks. WRT “RESTful SOAP”, that’s true; there is a dimension there that’s difficult to capture here. Perhaps that’s because “RESTful SOAP” treats SOAP as a format more than a protocol (see:, and most people (excepting yourself!) see SOAP as a protocol?

Yaron —

SOA is non-native to HTTP because if you’re doing that, you’re not using many (or any) of the benefits that REST gives you through HTTP. I suppose another way of saying it is that *all* of the architectural styles are native to HTTP, but HTTP certainly wasn’t designed with RPC and SOA in mind.

As to the other two questions, I wonder how clearly I wrote this; I didn’t say HTTP is necessarily RESTful at all; you can use it in a number of different ways, some of which aren’t RESTful. REST can be thought of as subset of SOA, as REST is just additional constraints (SOA isn’t addressed in Roy’s thesis, but it seems like it could be thought of this way; DaveO tried to formally define SOA as an architectural style, but that didn’t catch on).

Monday, November 7 2005 at 2:50 PM +10:00

Mark Baker said:

Re "Perhaps [...]", yes, I think that's it. SOAP as a peer to Atom or RSS, if you will.

Terminology wise, I do think SOAP's a protocol. Then again, I think XML and HTML are also protocols. A good rule of thumb; if it fits in a protocol stack, it's a protocol. P-)

Monday, November 7 2005 at 5:10 PM +10:00

Yaron said:

I spent a few years hanging around the HTTP WG when 2616 was being standardized to replace 2068 and to be honest I don't believe anyone there, if you had described REST to them, would have thought they were doing REST exclusively.

And I do know that a bunch of us saw and see HTTP as a generic application transport. That's why WebDAV, for example, ended up on HTTP. In fact the view that HTTP was a generic application transport was so common in the HTTP WG that the area director at the time, Keith Moore if memory serves, was on something of a quest to try and stop us from using HTTP that way in the IETF. That is why he wasn't the biggest fan of WebDAV and IPP made him positively cross eyed. He and I used to have long debates on the subject.

So I think attributing REST as some fundamental quality of HTTP and anything that isn't REST as not taking advantage of HTTP is revisionist history at best.

Monday, November 7 2005 at 8:13 PM +10:00

Mark Nottingham said:


Of course they didn’t know they were “doing REST”; it was defined afterwards, and Roy is very up-front about that in his thesis. REST just documents some of the design decisions that were made as more abstract principals.

Of course people had other things in mind for HTTP (indeed, we have CONNECT and the Upgrade header). Perhaps my statement was too broad; the sentiment was that the design locus of HTTP wasn’t around tunnelling, it was around what people now call REST.

REST isn’t about GET/PUT/POST/DELETE specifically, it’s about uniform methods, among other constraints, which *is* build into HTTP. WebDAV is RESTful, for the greater part.

Monday, November 7 2005 at 8:38 PM +10:00

pwb said:

REST is so annoying because it's just an "architectureal style", whatever that is. Can't someon codify it slightly so that people know when to do a POST and when to do a GET?

For the record, the beauty of non-SOAP, is that any novice CGI programmer can program against a reasonable robust API set that can be described in full on a single page:

Monday, November 7 2005 at 11:28 PM +10:00

Mark Nottingham said:

WRT POST vs. GET, I think that's a HTTP issue, not a REST issue. REST doesn't define GET/PUT/POST/DELETE -- it just says you need uniform, generic methods.

Monday, November 7 2005 at 11:38 PM +10:00

pwb said:

OK, I'll try to restate the question. People complain that Amazon Web services aren't REST but never explain why. Further, without any direction, how can Amazon figure out how to make them REST? An "architectural style" is darn near meaningless. Until someone comes up with even the slightest someting resembling a specification, developers will have a great deal of difficulty producing REST-ful interfaces.

Tuesday, November 8 2005 at 10:12 AM +10:00

Mark Baker said:

An architectural style *is* "direction". For example, REST says "use uniform interface semantics", which is easily testable (more or less). I admit it's not what a lot of folks are used to, but it's not rocket science either.

Tuesday, November 8 2005 at 4:53 PM +10:00

pwb said:

"use uniform interface semantics" doesn't mean anything to me.

I'd like to see a spec that leads to this: (or at least a REST-conforming version of this, whatever that may be).

The point is, the Backpack API is as complex as most APIs and yet is wholly approachable from even a novice CGI programmer.

Contast that with your average SOAP API which is difficult even for experienced develoeprs.

Tuesday, November 8 2005 at 8:19 PM +10:00

Terris Linenbach said:

Jesus Christ, would you people stop treating this like it's news? This is at least 100 years old in Internet time.

Data over HTTP gets the job done. I'm not even going to call it REST because XML is optional. SOAP is for the develoment tools vendors.

Tuesday, November 15 2005 at 6:58 AM +10:00

Creative Commons