“processThis” continued

Mark requests for clarification on my coupling argument between resource identity, the assumed representation (state), and the REST verbs in the “On the REST verbs vs “processThis” discussion” post. As always he makes a nice argument and thinks that an example would help. So, I’ll give it a go…

Let’s assume that two companies wish to start doing business together. One company (the consumer) will submit an order and will receive an order number from the other company (the service) for future reference. The consumer can check the status of the order, amend it, cancel it, etc.

I will try to abstractly describe how I see the two approaches being applied and, hopefully, Mark will correct me if my use of the REST concepts is not correct. Let’s assume for the purposes of this example that the REST approach uses HTTP.

The consumer submits the order (an XML document) at http://service.com/order using HTTP POST or PUT. The URI of the new order, http://service.com/order/123, is returned. The consumer applies a GET on the order URI and receives as a result a document describing the order, the representation. I assume that if the consumer wanted to get some other information (not its representation), the status of the order for example, they would have to apply a GET on http://service.com/order?status=http://service.com/order/123. Is this the way to do it? How would the consumer amend the representation of the order? Would they have to POST/PUT the updated version of the representation to the URI of the order?

You see, this approach suggests to me that there is a coupling between the representation (the order state), the identity, and the verbs you can apply on it. That’s because the resources become the logical entities that are the recipients of the requests, the interactions. Since the REST verbs assume certain semantics (the consumer can give or request representation) one has to come up with application-specific conventions in order to achieve the additional functionality required (e.g. adding a query to the identity of a resource in order to be able to check the status of the order).

What the “processMessage” approach suggests is that the consumer has to only send documents to a service endpoint. Unlike REST and WS-RF, it’s not a resource that is the logical receiver of the messages/documents but, rather, a service. I send an “OrderForm” document to a service endpoint and I get back an order number (urn:service:order-number:123). I send a “RequestStatus” document that contains the order id and I get another document back with the status for that order. I amend the order by sending a document to the service endpoint called “OrderAmendments” with the id of the order and the new information. You see, at no point I had to make any assumptions about any protocol-specific verbs and how their semantics may relate to what my application is trying to do. Of course, at no point I had to make any assumptions about the state of the service. That’s an implementation detail. I do assume that the state of the order is maintained by the service somehow but I do not care how this is done (I guess the same is true with REST).

Is this a reasonable example to use in order to try and understand the differences/similarities of the approaches? Most importantly, have I given justice to the REST approach to this problem?

I am not suggesting here that I have the answer. I am just trying to learn through exchanging ideas, so please be gentle 🙂