JJ Dubray has written a post on “10 questions a solutions architect should ask before using REST”. Some good points, and worth commenting. You need to read JJ’s post since I’m not going to re-iterate everything here, just add my perspective:

1. Can the solution be constructed from a series of roughly autonomous webparts that have independent requirements in terms of scalability, security, evolution and ownership? Do you foresee that these webparts will be used in different solutions?

JJ sees REST as the solution here; I agree.

2. Is your solution also about implementing complex processes that are likely to change on sophisticated business objects such as a an insurance policy or claim?

I’ll happily agree that if you’re after a BPM-style solution, REST is not the first choice. I have my doubts that you’re so much better off using WS-* Web services, but clearly there’s no equivalent of BPEL for plain RESTful HTTP, nor is there much support for it from the big vendors. My guess is that 90% of the REST community don’t want to have any of this, but I could definitely imagine that there could be some very interesting solutions there. I agree with Mark Masterson and wish JJ would apply his intellect there.

3. Does your solution require peer-to-peer inter-actions?

I see no problem with peer-to-peer interactions using RESTful HTTP, provided you’re able to run a Web server on both sides. I see zero advantage on the Web services side.

4. What are the implications of reducing application semantics to a uniform interface on your solution?

This is the main discussion I’ve been having with JJ in numerous emails over the last few weeks, and we simply can’t seem to agree. I believe main benefit of the uniform interface — connectivity, accessibility, however you might want to call it — far outweighs the mental shift you have to make to become comfortable with mapping your semantics to it. (There’s also a strange misquote of one of Roy Fielding’s slides here, AFAICT - he wanted to show the effects of not using a uniform interface, the most significant one of which is the lost GET possibility. It also makes sense to look at the full content of the slide JJ mentions.)

5. What is the impact of using Uniform Resource Identifiers as business entity identifiers?

Not everything needs to be identified with a URI, only those things you want to expose as Web resources. For those that have different requirements, you can still use whatever means is appropriate. In the WS-* world, there is no concept of standardized identification. Who would consider this an advantage? Yeah, me neither.

6. Is query by example combined with media types enough for building your solution?

That’s actually a pretty good point. There is no standard way of specifying URI templates (but one is emerging), and there is no standardized query syntax. Both would be a good idea. In the end, though, you can of course use any query format you like by POSTing it, thereby creating a new resource (the search result). Again, this is more, not less than what the WS-* world has to offer.

7. Do you want XML to be your primary means of exchanging information?

JJ uses an older Mark Pilgrim article that, despite the title, is basically concerned with XHTML, or rather: with the way browsers handle XML. It’s utterly irrelevant to the discussion we’re having here, particularly as SOAP is XML, and SOAP over HTTP is thus plagued to the same degree by the same problems.

Whether or not you use XML is 100% orthogonal to whether or not you use REST. There is a huge benefit in not having to force everything into XML, as it means you don’t have to use idiocies like this or that.

8. How do you propagate user identity?

Security in WS-* is arguably handled better than in the REST/HTTP world. Whether it’s particularly user identity propagation that is problematic, I’m not so sure. In many cases, SSL is sufficient even in WS-* scenarios — at least that’s what 99% percent of the installations are using (just a wild guess).

9. Do you need transactions in your solution?

JJ claims there are no transaction capabilities in REST. True. Don’t use RESTful HTTP if you want to synchronize multiple requests in a 2PC manner (and thereby tightly couple your systems).

10. Do you trust the RESTifarians to come up with all the specifications needed to establish robust server-to-server inter-actions?

Most of the stuff that’s available in the WS-* world is of questionable value, and I see no need to copy it. There’s one very funny quote, though:

Hardly anyone in the REST community has experience with writing specifications and major vendors have not yet moved in

I’m sure Steve Vinoski, Mark Nottingham, Tim Bray, Joe Gregorio, and many many others are really looking forward to writing their very first specifications soon. Who knows, maybe even Roy Fielding may end up writing one?

JJ, in case you haven’t noticed, some of the most vocal REST proponents are authors of specs — sometimes even of those of the WS-* kind. My favorite quote from Mark Nottingham, former chair of the W3C WS-Addressing Working Group, illustrates this nicely:

Show me the interoperable, full and free implementations of WS-* in Python, Perl, Ruby and PHP. You won’t see them, because there’s no intrinsic value in WS-* unless you’re trying to suck money out of your customers. Its complexity serves as a barrier to entry at the same time that it creates “value” that can be sold.