Web services needs Transfer protocols AND specific protocols
An interesting piece from David Orchard — I think REST principles are great, most of the time; if there’s a way to make something work just using REST’s resource-oriented style (in the XML over HTTP incarnation), I’m all for it. But although it’s clearly possible to map everything to a uniform set of verbs applied to all resources, that doesn’t mean that it’s a good idea to do so.
In a few J2EE projects we’ve done in the past, we faced a decision similar, at least in principle: Whether or not to use Entity Beans. Especially with EJB 1.1, it was totally impracticable to use Entity Beans for all persistence need out of simple performance reasons; even with EJB 2.1, it’s still not possible to stick to using Entity Beans only, e.g. if you need dynamic queries. What we ended up doing was using Entity Beans for transactional updates and plain JDBC for reading (keeping both methods synchronized by relying on a single model, but that’s another story).
I strongly suspect we are going to end up offering the bulk of our functionality via generic REST interfaces, mapped both to plain HTTP as well as (something resembling) WS-Transfer, and a smaller set of specific functionality using a more constrained schema. After all these discussions, I’ve still not made up my mind whether this functionality is best modeled as services with a single ProcessMessage() API, as Savas suggests, or with more specific operations, though …
Stephan:
I think I found an argument that makes pure REST invalid for most business applications.
If a resource is a resource in its entirety, it is not practical to share this resource with just any service. What typically happens is that a partial representation of the resource is shared. Once this happens you need a dedicated verb indicating what partial state you want and what to do with this image of the partial state once it is sent back. This is where verbs like “process” “create” “cancel”… appear. OAGIS has proposed a series of business verbs (a small number). I believe this is still RESTful, but the purest may disagree with me. Did you have to front end your transactional updates with verbs such as create, change, cancel, or were you able to transfer the logic of “cancel” to the client? (I’d be surprised if you can since that would require the client have the knowledge of everything that is related to a purchase order and take decisions on what to do with them in case a PO is canceled -> stop production, notify bill, call UPS,…).
On another note, I have invited many times the restifarian to create the metamodel of REST and compare it to the metamodel of SOAP. I frankly can stand the hacked URL syntax. That approach would probably resolve the processMessage() question. There is an incompressible number of semantics that are needed, this is the real question.
I would also be curious to know if the RESTifarians consider SQL Restful. I would also be curious to hear how SQL and the concept of service can be aligned. If it is not, try to convince people designing business applications without SQL ;-)
This debate is a dead end and the conclusion has long been known.
Cheers,
Jean-Jacques
JJ: I think that accessing or updating only parts of a resource would still be RESTful; this could e.g. be done by addressing an element within a resource with a fragment appended to the URI. (But that’s probably what you meant by ‘hacked URL syntax’.)
I also think that uniformity is a main aspect of what REST is about, so if you stick to a set of verbs other than GET/PUT/POST/DELETE, that would be fine as well.
As to SQL, I guess it doesn’t get much more RESTful then that :-)
Well the problem I have is that RESTifarians always respond to architecture questions by saying “add this thing here or there”. (If we expand the character set we can even compress more semantics in less bytes). When you say a fragment appended to the URI, I don’t mind if at the implementation level this is what happens, but I would like to discuss the semantics of this fragment, how do they relate to what is supposed to be the set of semantics you will ever need to have for REST. I consider cheating if you add meaning other than the verbs and the resources (nouns). (I am not surprised why the RESTifarians tend to avoid going at the conceptual level).
For SQL, sure, the verbs are few enough to look RESTful, but could you elaborate on the “resource” aspect of SQL. How different are two SQL statement s targeting the same row with different attributes? Is it two different resources? Can REST support the notion of partial state?
There is always so much handwaving in using REST for what it cannot support readily.
On another note, I never seen “clients” deciding where their bytes should be re-directed to a different server, what if I want/need to transform the state I got into another state before I send it to someone else. I am sure someone is going to tell me, hack this or hack that and you can do it. In pratice, this never happens in a so called RESTful application.
JJ-