Comments on: Design Characteristics of REST / Resource Oriented Server Frameworks and Clients http://blog.dhananjaynene.com/2009/06/design-characteristics-of-rest-resource-oriented-server-frameworks-and-clients/ Dhananjay Nene's opinions on software programming, design, architecture and the internet Sun, 28 Feb 2010 03:58:25 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Musings on REST | /var/log/mind http://blog.dhananjaynene.com/2009/06/design-characteristics-of-rest-resource-oriented-server-frameworks-and-clients/comment-page-1/#comment-8709 Musings on REST | /var/log/mind Fri, 26 Jun 2009 17:29:44 +0000 http://blog.dhananjaynene.com/?p=690#comment-8709 [...] Design Characteristics of REST / Resource Oriented Server Frameworks and ClientsThis post dwells into the many aspects of design of a REST or Resource Oriented Serverside Framework and attempts to enumerate a large number of their characteristics. One of the aspects it brings up is the role of the Controller. Since the a resource oriented interface primarily consists of basic primitive operations on resources, it suggests that the controller could either be merged with the Resource or support only basic operations and have a one to one relationship with a resource. This is where a potential differences with conventional frameworks arise. If I was to think of it from an EJB like perspective, I would model a OrderController as a Session bean and a Order as an entity bean. In case of lightweight POJO based model, I would have an OrderController as the endpoint exposed by say using Struts and model the Order as a entity POJO and map it to the database using Hibernate. In other non java frameworks, I would have a class to represent an OrderController and another one to represent the order along ActiveRecord pattern. But I would argue this separation is not entirely necessary, since what we want is something that implements a single abstraction mapping onto a Resource which also support the primarily lifecycle methods or resource operations of GET, PUT, POST and DELETE. But there is an issue to be worked through here. These resource operations are actually class level and not object level methods. Thus if we have an abstraction to represent the resource instance, the class level methods cannot be defined in the same class except as class level (static) methods. This is a tricky problem, and I would submit the designer may make one of two choices (a) Implement the resource operations as class level methods on the Resource abstraction (ie. they will get or return the resource references as method parameters and not rely on the ‘this’ or ’self’ qualifier for getting access to the resource variables or (b) Implement the resource operations as methods on a separate one-to-one mapped class on the resource abstraction (eg. an OrderHome in case of an EJB like analogy) [...] [...] Design Characteristics of REST / Resource Oriented Server Frameworks and ClientsThis post dwells into the many aspects of design of a REST or Resource Oriented Serverside Framework and attempts to enumerate a large number of their characteristics. One of the aspects it brings up is the role of the Controller. Since the a resource oriented interface primarily consists of basic primitive operations on resources, it suggests that the controller could either be merged with the Resource or support only basic operations and have a one to one relationship with a resource. This is where a potential differences with conventional frameworks arise. If I was to think of it from an EJB like perspective, I would model a OrderController as a Session bean and a Order as an entity bean. In case of lightweight POJO based model, I would have an OrderController as the endpoint exposed by say using Struts and model the Order as a entity POJO and map it to the database using Hibernate. In other non java frameworks, I would have a class to represent an OrderController and another one to represent the order along ActiveRecord pattern. But I would argue this separation is not entirely necessary, since what we want is something that implements a single abstraction mapping onto a Resource which also support the primarily lifecycle methods or resource operations of GET, PUT, POST and DELETE. But there is an issue to be worked through here. These resource operations are actually class level and not object level methods. Thus if we have an abstraction to represent the resource instance, the class level methods cannot be defined in the same class except as class level (static) methods. This is a tricky problem, and I would submit the designer may make one of two choices (a) Implement the resource operations as class level methods on the Resource abstraction (ie. they will get or return the resource references as method parameters and not rely on the ‘this’ or ’self’ qualifier for getting access to the resource variables or (b) Implement the resource operations as methods on a separate one-to-one mapped class on the resource abstraction (eg. an OrderHome in case of an EJB like analogy) [...]

]]> By: Dhananjay Nene http://blog.dhananjaynene.com/2009/06/design-characteristics-of-rest-resource-oriented-server-frameworks-and-clients/comment-page-1/#comment-8116 Dhananjay Nene Wed, 10 Jun 2009 22:07:36 +0000 http://blog.dhananjaynene.com/?p=690#comment-8116 @Blacktiger We're probably suggesting a similar solution but for slightly different reasons. Current frameworks especially those implementing the pure MVC model are based on exporting Services through the Controllers. To the extent the goal is to export services, Controllers probably are the right place for that functionality. However I would still buy your argument that the framework could automagically handle that stuff for you. The slightly nuanced difference I intended to bring out is that in a Resource Oriented Framework, the Resource is the end point and the handler should have the logic. In such a situation the controller is not the right place for the functionality because the controller is not necessarily the most appropriate abstraction. Either way you look at it, it of course makes sense to have the framework implement as much of the boilerplate stuff for you as possible. @Blacktiger

We’re probably suggesting a similar solution but for slightly different reasons. Current frameworks especially those implementing the pure MVC model are based on exporting Services through the Controllers. To the extent the goal is to export services, Controllers probably are the right place for that functionality. However I would still buy your argument that the framework could automagically handle that stuff for you.

The slightly nuanced difference I intended to bring out is that in a Resource Oriented Framework, the Resource is the end point and the handler should have the logic. In such a situation the controller is not the right place for the functionality because the controller is not necessarily the most appropriate abstraction.

Either way you look at it, it of course makes sense to have the framework implement as much of the boilerplate stuff for you as possible.

]]> By: Blacktiger http://blog.dhananjaynene.com/2009/06/design-characteristics-of-rest-resource-oriented-server-frameworks-and-clients/comment-page-1/#comment-8114 Blacktiger Wed, 10 Jun 2009 21:31:54 +0000 http://blog.dhananjaynene.com/?p=690#comment-8114 I've been thinking the exact same thing recently. Most web applications pretty much expose their models directly to the web front end, so why not have a framework that handles this stuff for you? It seems silly to have to hook up a bunch of controllers that do the same thing over and over. I’ve been thinking the exact same thing recently. Most web applications pretty much expose their models directly to the web front end, so why not have a framework that handles this stuff for you? It seems silly to have to hook up a bunch of controllers that do the same thing over and over.

]]>