08/03/08 :: [REST] Designing RESTful Rails Applications [permalink]
This is one of the better presentations I have heard on REST. Obie Fernandez did a real good job at analyzing how actions in Rails can be translated into RESTful HTTP calls. In MVC you can't escape actions. I like his approach of recommending to translate action verbs into an HTTP verb + a noun. For instance:
Login -> Create Session
Reserve -> Create Reservervation
I just want to point out that the semantics of a "link" are different from the semantics of a "relationship". A link is a unidirectional association (the association can only be navigated to the target of the link, the target itself has no way to know what's linked to it). A relationship as in Entity-Relationship is intrinsically bidirectional. When you have established a one-to-one, one-to-many or many-to-many relationships between two records, you can by default navigate from one to the other. So that leads to an important question, if you want to be RESTful, how do you establish bidirectional relationships which are the norm in enterprise information models? I know you are going to tell me very easy. Let's take an example with customers and orders.
When a customer creates a purchase order, we post the new order to the /customer/{id}/orders and we return the newly created URI:
/customers/{id}/orders/{PONumber}
So somebody getting this PO representation would "know" that it is a PO for the customer /customers/{id}
Of course this someone has to "know" that's "where" you find the customer foreign key, but let's leave this discussion, I have beaten this dead horse.
There is another twist to building RESTful systems. This one is a lot more interesting to discuss. This little URI scheme that I introduced above only works if customers and orders are co-located behind the same network location. If I want my customers to be managed by SalesForce.com and my orders by NetSuite, I am out of luck. I have no other choice than POSTing my order to NetSuite and PUTing the URI somewhere in SalesForce, aie, ouille, %^@&*(#, not good at all.
After uncovering that a Human has to be in the loop for REST to work properly, there is yet an untold constraint that is a bit more surprising, REST after all, does assume a form of boundary: the network authority on which the URI depends on.
That's why Jim Webber is trying to teach us that "cohesion" and "loose coupling" go together. You must think very hard about Cohesion principles when you use REST. Since pretty much everything in an enterprise data model is related to "customer", you get the picture.
(With my Steve Martin accent) But, of curse thiz iz nut strung cupling. "True" lousse cupling wuld require zhat "access" iz different frum "identifier", it iz u bit like mixing sume Brie with du saucisson. Zhis iz vhat happenz vhen yu uze one semantic fur anutheur.
The second question, still in light of bidirectionality is what do you really gain by translating all these actions into RESTful calls if in the end, in the database you have to stitch links into relationships? Obie did not talk about how the implementation on the server side would look like. This is a real loss. It would have been really interesting to see that. Maybe Stefan one day will initiate the REST of us to these secret rituals.
So if you are just marshalling MVC actions into HTTP calls and then unmarshalling them on the server to actually call the right stored procedure or SSLB, the question is what do you gain? Caching, no, no benefit there, have you heard about Entity Beans before? Caching enterprise data is not very rewarding. How many times the same customer can call your service desk in one hour? Caching bank accounts or policy insurances would be a bad idea. Anyone cares to answer this question? what do you gain?
At the end of the day, REST is a complete fraud and everyone knows it.