Design Characteristics Of Resource Oriented Server Frameworks

Posted by Dilip Krishnan on Jun 11, 2009

Sections

Architecture & Design,

Enterprise Architecture

Topics

Design ,

REST ,

SOA

Tags

Frameworks

Dhananjay Nene, who has also written a nice article that chronicles the history of REST, examines the various characteristics to be expected when designing a server side Resource Oriented Framework (ROF). The article also attempts to capture the relationship with a fine grained object model of an application and its’ resource model.

According to Dhananjay quite a few of these are taken for granted as a result of popular frameworks such as Struts, Django, Ruby on Rails etc. However enumerating them explicitly makes for defining the characteristics that make these resource oriented frameworks successful and popular. Examples of these characteristics of an ROF that Dhananjay observes are

A ROF will have an abstraction to represent a resource as an end point

If I was using an Order as a resource and if I introduced an approve method on the OrderController that would not be consistent with this requirement. That would need to be modelled as an OrderApproval resource which may on successful completion, effect a state change on the Order resource to the status ‘approved’.

Given consistent expectations of the Resource Operations these will actually be auto-magically implemented

A ROF may provide additional support for typical aspects of lifecycle (eg. validation)

The resource interface methods will be implicitly implemented by the framework [and] the framework will allow the developer to plug in / override his own implementation [and support lifecycle tasks for e.g. validation].

A ROF will provide capabilities to a developer to override or register methods to handle downstream impact of PUT, thPOST and DELETE

I have drawn the analogy that a REST based system is like a DBMS where client applications can perform direct SQL such as SELECT, INSERT, UPDATE, DELETE (GET, PUT, POST, DELETE in case of HTTP/REST) on the Tables (Resources in case of REST), and the business logic is implemented as triggers. Thus the framework will need to allow the developer to define such triggers.

A ROF will provide a mechanism to describe or map a resource abstraction to to the actual programming constructs

There are a number of ways this could be achieved. XML, YAML, DSL, Annotation - take your pick. Also the actual class could be defined (as in case of a POJO) and the resource characteristics mapped onto it, or the class may manifest itself at runtime based on metaprogramming around the metadata. That the framework will allow [object model] relationships to be described or introspected.

A ROF will allow foreign keys across resources which manifest themselves as URIs to be mapped onto the underlying business object references

Resources refer to each other through URIs. The underlying business objects refer to each other through object references. Given the resource descriptions and URI mappings, the framework should allow for a transparent referencing/dereferencing between such URIs and the object references.

While most of the enumerated facets of an ROF seem natural for RESTful services, some characteristics do seem like they need further explanation or examination or perhaps just a elaboration witconcrete examples.

A ROF will allow factory methods for locating or allow injection of other resources / business objects

The developer may choose to interact with these at a coarse grained (resource) or fine grained (business object) level. The framework should allow the necessary support for such activities.

A ROF should allow for the resource / media-type descriptions to be shipped in band with the resource representation : Since REST allows media types to be auto discovered and auto described, the framework should allow for the metadata for such media types to be also presented to the client. The actual metadata could be represented using any of the typical appropriate standards such as RDFa, XML Schema snippets etc.

Though the facets that Dhananjay enumerates are fairly comprehensive, the article does not address some of the non-functional requirements for e.g. support for monitoring, auditing / logging, transaction management, object pooling.  Be sure to read the original article for details.

• Older >