REST Truer To The Web Than WS-*

Mark:

the question that I generally see missing in this kind of argument is: "Is the Web a good model for Enterprise Applications?". In other words, can I model Enterprise applications as a set of resources with a uniform interface?

We have seen last week, that even Tim Bray can't do that. That's quite a setback if you ask me.In his post, he explained how he had to introduce a controller and model actions with verbs. Yacks... Tim's implementation of Sun's Cloud API opens quite a big can of worm.

So we can criticize WS-* for all kinds of reason, I don't mind -we both know how much politics there is baked in- I have no vested interest in it, but at the end of the day, the REST supporters are not using REST in a resource oriented fashion simply because enterprise systems look nothing like the Web and can't be modelled via a series of resources implementing a uniform interface.

So it is pretty clear how all this will end up. As they integrate more and more applications with it, people will first get URI template fatigue, then they'll realize how much of a mess having all these schemaless resource representations creates... so they will start creating all kinds of libraries to automate work that seemed cool to beging with, and we will have accomplished another middleware iteration.

In order to make sense of this discussion, we have to ask ourselves which part of web services we are concerned with – web or services? If the answer is web, then Rest argument about alignment with HTTP and Web in general does make sense. If the ahe answer is services (that will be my answer), then the world web is more historical, than practical and alignment with HTTP/Web is irrelevant.

There is merit to think about accessing enterprise data in a Web oriented way, but again the Web architecture never thought in terms of actions and events as this data gets updated in an orderly fashion, so trying to align that aspect -that I would qualify as Service Oriented and Event Oriented- with "the Web" is no just irrelevant, it is simply doomed to fail. Tim Bray seem to have come to that conclusion.

It is, IMHO, an error to oppose resource orientation to service orientation simply because 'WS-* standards ... are too much of a moving target'. If that's the problem, let's fix the problem. Ultimately resource orientation, service orientation and event orientation will have to coexist as none can be reified in the others' formalism.

Just to be clear Bill's comment 'Bill says that REST isn't anti-SOA' is not correct. REST is by definition anti-SOA since there are no "service" concept in it. There are no service boundaries, no contract, no way to define and monitor SLAs (on what? resources?), no versioning ...

The shift of one endpoint per service to one endpoint per resource is significant. Service Orientation is simply incompatible with one endpoint per resource.

I think Boris hits it on the head. There's two parts to web service, the web and the service. On one side you have people who wants services that can leverage existing infrastructure (WS-*), and on the other side, you have people who want the web as it exists, but consumable (REST)

Being a web service guy myself, I think the future of that path is with frameworks like WCF, that can leverage web services, but can really swap them for anything if needs be. The "web" part is just a convenient technology, but by no mean a centerpiece in its development. Its just "there", so we use it, but if it vanish, we won't lose sleep over it.

Thats why both REST and WS-* need to stay, and why the argument as a whole is irrelevent...they answer totally different business needs.

Francois, it seems to me that the amount of existing infrastructure you can leverage when using RESTful HTTP vastly exceeds the stuff available in the WS-* ecosystem.