REST Design Concepts

In exploration of REST as next architecture revolution after SOA, I though of defining few fundamental steps in designing a RESTful System. Here is my take on it.

Define Entity:

• Identification of resources
• Entities have uniform names
• Every entity has its own name and uniform location
• An Entity is anything that can be individually named
• Most database tables are logically entities, but usually a RESTful entity includes much more data than just a single row
• Entities get URLs
• Access the current state of that entity using that URL
• Change the state of that entity using same URL
• Entities have relations between them
• Most clearly represented as hypertext
• Nothing stops you from delivering related entities with each other
• Can deliver groups of entities at once, either as hypertext lists or as batches of actual content 

Choose Operations Set on Entity : 

• Manipulation of resources through these representations
• Use A Limited Set Of Verbs 
• HTTP Put, Get, Delete, Post all you need for CRUD operations

Choose of Protocol:

• HTTP is the most prominent, but FTP, SMTP, JMS, HTTP, Directory Scanning can all be used

Choose Data Transport and encoding styles

• HTML, JSON, CSV, FIX, XLS

Define transport and communication protocol: 

• Self-descriptive messages
• Use Content Negotiation 
• Client says what it can support, server gives it the best match
• XML excellent for RESTful integration
• Use of tooling or hand parsing using XPath or DOM walking
• HTTP excellent protocol
• Client-initiation helps satisfy HATEOAS principles and avoid pumping data into the ether
• Can use huge set of HTTP based assisting technologies
• Everything speaks it
• Any language which can’t process XML over HTTP will be extended or replaced by one which does
• Solves the Excel problem

Design Client Interfaces:

• HATEOAS Principal - Hypertext As The Engine Of Application State
  
• Client applications navigate through links
• Clients never assume anything about the internal structure of the application beyond the defined content encoding
• In particular, “deep-linking” should be avoided wherever possible!
• Don’t store client context or state on the server, keep it with the client
• Resource providers don’t know anything about how a client is navigating through the application, so can scale better
• Allows providers of resources to manage them
• Can change hosts, protocols, encodings based on client and configuration details without clients having to be updated
• If your application has a single URL that defines entry to the system, yer doin’ it right.

JAX-RS: JSR-311 
Reference implementation 

1. CXF - which is a merger between XFire and Celtix (an Open Source ESB, sponsored by IONA and originally hosted at ObjectWeb).
   
2. Jersey - JAX-RS Reference Implementation from Sun.
3. RESTEasy - JBoss's JAX-RS project.
4. Restlet - probably the first REST framework, which existed prior to JAX-RS.

Developer Community Opinion:

• Jersey is meant as a reference implementation. 
• RESTEasy is a playground for new ideas. 
• CXF has an "enterprise version" supported by IONA. 
• Restlet project grew out of a desire to have a RESTful API alternative.

References: 

• RESTFul Integration
• Presentation Slides
• InfoQ Presentation
• http://benramsey.com/media/talks/phpworks07-rest.pdf