For instance, one of my opinions in SOA is that it is a myth that BPM is the natural couple of SOA. It treats SOA as a component that supports BPM. This is also converting SOA into an artifact that has no much value on its own if not used to support BPM. Furthermore, many BPM implementations are so focused on the IT part that forget BPM is all about business.
(This and other myths about SOA I presented in a short video in the Architecture Journal from Microsoft, in case you wonder)

So, getting back to the discussion of contracts, it is clear to me that there should be a shared knowledge, implicit understanding of concepts, a glossary (think IANA as a repository). As a user reads a login form and understands what to do, so an agent should be able to get a content type and know how to read it. It is like playing a chess game: not two games are equal, but you can play since you know how to move the pieces.

REST is extremely difficult to catch. HATEOAS is the least understood. That is what the goal is, at least to me: discuss until everybody is in the same page.

One thing is clear, and both of you got it right: SOA is not REST, and Services are not Resources. Now, SOA and REST are not aimed to the same goal either.
REST is a networked, hypermedia oriented style.
SOA is a business, message oriented one.
I would not have much problem to choose one of them
And If I need BPM, I would think first how is my solution architected. I would never replace BPM with REST, that makes no sense to me!

Cheers!

Not me. That’s why I worked on RDF, which has an actual formal semantics. It happens to use URIs for identifiers but that’s not critical to the model theory. So given that mistake, the rest of your post doesn’t need refuting.

By the way, does the BPM family have semantics, or is it still scripting hooks doing the real orchestration work? That’s no more or less lala that saying a client can transition application state by traversing links.

>> REST precludes mandatory aprioriness (eg. as required by WSDL), it does not preclude aprioriness per se.

We agree violently again. So why don’t we make all that very clear and you ask/convince your RESTafarians colleagues to stop making these lala claims that metadata automagically flows and HATEOAS can be used serendipitously in server-to-server scenarios.

>> it does not preclude aprioriness per se.
What is the point of using “documents” when you can have a machine readable artifacts? You think that “hand coding” is better than tool generation?

>> CRUD is not only good for, but is the only consistent way to build REST over HTTP.
CRUD is the worst coupling you can establish between two software agents, even between a human and software agent.

Great to start off with an agreement on the fact that resource orientation and service orientation are two very different ways of approaching a problem, and REST does not emphasise service orientation. However this agreement quickly fades when we get to the remainder of your comment.

and that’s the major lalaland argument of RESTafarians, the exchange of arbitrary metadata between two software agents without an a priori agreed upon meaning of this metadata is at best dangerous if not plain stupid

I cannot recall any single reasonably formal documentation about REST which asserts what you state above. What REST recommends is that you ship in band information so that apriori meaning of data is not mandatory – which is entirely different than saying that it precludes any apriori agreement. The tolerance to lack of apriori information is a function of the client agent sophistication – and we shall see agents with a variety of sophistication levels. I cannot imagine in the short run, sites offering REST APIs without offering documentation on the resource metadata. Thats why many sites which to offer REST / REST like API offer documentation wikis which break down that information about media types in some level of detail. REST precludes mandatory aprioriness (eg. as required by WSDL), it does not preclude aprioriness per se. Such apriori communication is really outside the scope of the agents and usually through simple wiki pages today. In the context of HATEOAS, there again is required some apriori information on the link types and media types. The apriori information that is not required is the URIs themselves. If you really look at it carefully – the aprioriness exists here too, its just been driven higher by one level of abstraction. Thus when agents can be built to a sophisticated level of capabilities, REST allows a mechanism of in band metadata communication that is not supported by WS-*. Thats the real difference. I think the danger and stupidity you state is a result of a misunderstanding that should be corrected.

As soon as you understand this point you realize all that is missing in REST to make it useful for anything as you build an Enterprise Solution, and frankly it is the main reason why RESTful examples are limited to simple, often CRUDish data access APIs because these don’t require much metadata exchanges.

Thats inconsistent with my understanding. REST examples are CRUDish because of the uniform interface imposed by HTTP. In fact I dwell in a fair detail on the topic in my earlier post CRUD is not only good for, but is the only consistent way to build REST over HTTP. Just like I made the distinction between service orientation vs. resource orientation, I would like to make another distinction between using CRUD for data access (as conventionally understood) and CRUD for resource access (as usually used in REST). The apparent simplicity of the CRUDish APIs is actually a strength when you view CRUD from a resource orientation perspective.

thank you for your response. I am glad we are in agreement that REST is not service oriented, and it is not because REST IS-A Service (not sure everyone would agree with that) you can build service oriented solutions from it.

As you may know the relationship between BPM and SOA is one of my dearest topic and the main reason for expressing so much negativity about REST. BPM has been crippled by extremely naive visions of what a business process is and unfortunately REST is pushing BPM further back. I have written an article explaining the relationship between BPM, resources and service orientation. I have even created a concept called WSPER to support it. Here is a link to the article: http://www.infoq.com/articles/seven-fallacies-of-bpm

When you describe a process in REST
>> The focus here is the tasks being done and the protocol for the task instructions. …

I am not sure you ever wrote one using the REST principles you describe. In case you have not noticed, and that’s the major lalaland argument of RESTafarians, the exchange of arbitrary metadata between two software agents without an a priori agreed upon meaning of this metadata is at best dangerous if not plain stupid. You either need a shared taxonomy or you need an out of band negotiation of the meaning of “data structures, actions,…” saying “I just ship metadata from A to B and automagically B understands what to do” does not make any sense. This is what -ALL- the RESTafarians are claiming. It (kind of) works when B is a human using a browser, it always works for sure when REST is limited to be the “Web Page CRUD Service” for which it was originally designed, but it is criminal to drive scores of people to believe that metadata can be exchanged without any a priori agreement.

As soon as you understand this point you realize all that is missing in REST to make it useful for anything as you build an Enterprise Solution, and frankly it is the main reason why RESTful examples are limited to simple, often CRUDish data access APIs because these don’t require much metadata exchanges.