Jean-Jacques Dubray has written a list of problems with REST. Let's step through them.

"intermediaries: to help you perform security checks, routing or transformation at wire speed. You are not even on your own there, REST can't do it."

This is a "that's not even wrong" statement. See the cache constraint in Fielding's thesis. Maybe Jean-Jacques is talking about hop by hop routing, where the router is a first class component in the message flow; well I think we can say that model's more or less broken.

"interoperable reliability: REST has tricks, but not a spec. How to you do message ordering in REST? well you don't, you are on your own"

There's more to reliability than message ordering, surely. Both I and Yaron Goland have proposals for reliable messaging over HTTP. Mark Nottingham has an Internet-ID for once and only once update of state. When you consider the scaling and state management characteristics REST is trying to cater for, then sequencing is neccessaraily something you layer on top; and when you do you do it at the endpoints, not in the network or in the intermediaries.

If you handle transfer in accordance with REST's statelessness constraints you don't hit this kind of reliability issue as much. Wanting to know or control the order of messages received is related to not being able to talk to business resources directly. I think if all you have are services, then you have start worrying about out of order process calls. Instead what you could be worrying about are the state of resources and legal state transitions, assuming your world view caters for such things. I'd wonder if SOA neccessited process orchestration, if there was a concrete SOA style to actually study.

I think if you're looking for a fundamental important distinction between "ROA" and "SOA", the contrast between service coordination and resource states are where you will find it. And maybe we can't just all get along.

 "contracts: how can you do versioning in REST?"

This one has substance. But let's be clear on this; the contract/versioning techniques I've seen for WS/SOAP  do introduce complexity. The additive approach of must ignore is a far better place to start than tight schema versioning. I guess when you are service oriented versioning becomes an important problem because you've modelled the world as a sequence of process calls.  Anyway versioning is a special case of the naming problem, which is intractable, so be wary of people who say they have cracked versioning; there's going to be increased complexity somewhere else in their architecture.

In REST to version a resource barely makes sense (what does it mean to "version" a House, or a Car?), but you can manage this to some degree through URLs - each new version is a new thing - or through representation formats returned on GET or accepted on POST/PUT.

 "peer-to-peer: Roy fielding himself say REST can't do peer-to-peer it has to be "relaxed". You are not even on your own there, REST can't do it."

And this is a problem, how? Why would REST do this, when it's designed out via the client server constraint? If you don't agree with the constraints, that's another thing - design an architectural style to support it, assuming you really need P2P. [Important Technical Note: P2P is not the same as full duplex comms, or client/server to client/server twinning that protocols like BizTalk's BTF2.0 do.]

 "Dependency of Injection: DofI of resources? no, not really, since REST does not have the concept of a service, you can't do DofI, you can't arbitrarily replace the root of URIs, on the fly."

I have no idea what this means, based on what I know about DI for Java software. Truly.

 "pub / sub: that's an obvious one, REST simply forbids pub/sub all the way. You are not even on your own."

See above point re P2P. And this time we can say that there is an architectural style that supports PubSub. See Rohit Khare's ARRESTED thesis [pdf] for the style and how it was derived. I have to wonder about this kind of criticism - it's like criticizing a car for not being a boat - but why are you looking at cars?

 "Orchestration: the REST camp, with people such as Steve W. says, I can do with a little script. You simply have no idea what you are talking about. [...] Orchestration style code is hard to write, it is extremely stateful, need to handle correlation and concepts such as hydration and dehydration. REST can't even do correlation because it does not have a contract. There are no XSD associated to a resource, a resource is only defined by its URI."

The problem with orchestration plus services is how application state is presented and modelled - you are worried about mesages arriving or not arriving, and relative ordering of operations,. The only way to express those worries is by sending more messages or passing conversation-ids around to reconcile work done to date - you do this because all you have to talk to are services/processes, which need to expose query instrumentation to answer questions. In OO terms, it's like all you can talk to are the manager classes; the domain objects are locked in the cellar and can't be spoken to. But if I am using a resource oriented architecture, I should be able to ask a resource whether it has received order XYZ or reserved seat ABC, irregardless of how many times a transfer was made. The orchestration issue becomes knowing who to ask about what.

I expect there are many cases where orchestration is not needed; work can be done by asking resources for their state. That said, I'll buy the notion that there are some cases where formal orchestration is valuable. I'll even ignore the idea that orchestrations and coordinations in distributed environments are Byzantine in the general case and thus can't be formally modelled (and hence do in fact require scripting, along with human intervention for exception management). But imvho, the BPM "camp" need to do a much better job in explaining why orchestration is important and neccessary. If it's just about writing less "business logic" and keeping systems flexible as businesses change their processes, fair enough - tell enterprises and their IT consultants stop banging out that logic in compiled systems languages like Java/C# and use Prolog/Drools/F# or some such instead.

I'd also like to know why said orchestration cannot be achieved on top of REST; that is, which of the REST constraints prevent either orchestration itself or solving the problem orchestration is meant to solve. 

 "Resource update: ..."

Read it yourself. According to this, publishing content, file upload or general state transfer can't actually be done on the Web, and running Subversion over WebDAV is clearly impossible. So probably I didn't understand the point at all.

"I'll repeat what I have said, I am not anti-REST, REST principles are great, REST style makes sense and you should apply it wherever your can. I am anti WS-Bashing. Both WS-* and REST have room to grow and make sense. It makes no sense to oppose them: they need to learn from each other."

All I can guess at is that Jean-Jacques is seeing nonsense designs being shooed in and justified as being RESTful and felt the need to push back. If Jean-Jacques thinks he knows specifically where REST is inappropriate to apply, that would be a great post to read.

Now that REST is cool by assocation, I wonder how much material like this we'll see. Sometimes I think I liked it better when deploying to the style or saying that WS-* was out of control put you squarely in the lunatic fringe (that's not even two years ago).

In the spirit of things, here are some questions to ask of REST before you start using it:

• Does it do what I need it to do? Consequently, do I even know what I need done?
  
• Is the style internally coherent, does it meet its own goals?
• How do I deal with content negotiation?
  
• Security?
  
• Batching?
  
• Workflow?
• Guaranteed once and only once delivery?
  
• What if I need to send unsolicited responses?
  
• Services (yes, they do exist)?