Mark Baker, Jeff Schneider, and others are going around on the WS / Rest debate. (Hey, has there been a live debate on this anywhere? Saved to the web?)
Mark says WS is unnecessary, that HTTP will do. Jeff says, yes but all kinds of things will do. It seems to me in this argument, Jeff should get down to one selection or at least begin to lay out his criteria for when to choose one or another. But...
The funny thing is, I'm a REST fan - I just can't stomach this one-sided bullshit.
But if Jeff is a REST fan then *when* is he a REST fan and when not? Jeff thinks Mark's stance is BS, but Mark is consistently towing the line on his choice. Exactly how does Jeff propose choosing one or another approach in any given setting?
As for my own semi-informed, partially-formed opinion, aren't the constraints of REST in the form of HTTP providing a more *broad* set of capabilities? i.e. an HTTP-based resource-representation-centric approach can be used by all systems that understand that architecture, which includes all the software written for the web already. (That's pretty substantial. 8^)
However if you take some other approach, say WS, then which WS standards do various vendors support? Big problem from what I can see. Then suppose you want to leverage all that existing web stuff. So you have a WS to get some resource in some representation and you want the representation to include a form that will POST requests to update the resource. From what I can see you still need to implement the REST model using HTTP anyway to do this. So why the WS?
So is the question just this: is the representational state transfer approach going to form the core of your architecture or not? If so, use REST. If not, then *what* will your architecture be?
For some situations I could see adopting some other architecture in conjunction with REST. Within some boundary, say an internal set of IT data centers, I could see using various architectural approaches that are more along the lines of what you put *behind* the REST-ful applications. Here you need a request dispatching and approval architecture, a caching architecture, a query architecture, a systems management architecture, and so on.
When I listen to vendors talking about Enterprise Service Busses this is what I think I am hearing -- how do you implement the data center itself? GET should be fairly ubiquitous. Then there would uses of POST, PUT, DELETE, etc. but maybe not so ubiquitously. i.e. eventually there are databases of various kinds: relational databases, file systems, and tuple spaces may form the core, if not completely in their current form.
There are two architectural questions it seems to me -- what do you present as an abstract programming model? And what do you use to implement that model? I am not sure there are enough constraints around a general WSDL model. More constraints are needed to guide the specific model. What do you think they should be?
