For the past few years we have seen the growing popularity of blogs,wiki,social networking sites as a part of the Web 2.0 paradigm.Most of these sites are exposing API or services which are accessible over web to enhance the level of collaboration.From technical perspective these APIs are of two types:
- Services complying to the WS-* protocols exchanging data as XML based SOAP format.
The WS-* protocols and SOAP has evolved as part of SOA where the main goal was to achieve a platform/vendor neutral mechanism of distributed computing organizing the architecture around the concept of service.
With advent of Web 2.0 the second category of services I mentioned above are growing in popularity because of their lightweight nature and ease of use.Whenever I discuss about this kind of services with my friends they refer to the term RESTful services.This I feel is not correct.All HTTP based services that does not use SOAP should not be referred to as RESTful.A service is RESTful or not depends upon how you conceptualise the design of the service rather than what technology or data format you use.This is what I would like to substantiate in this post.To make this difference clear and crisp I need to discuss about REST first.
Why we call Intenet as WorldWideWeb?.This is because it is a web of linked resources,we request for a particular resource and what we get is a representation of that resource.This representation may contain a link to another resource and thus we navigate from one resource to another.This is the basic concept of REST.REST is how the WWW actually works.
The term REST (Representation State Transfer) was coined by Roy T Fielding in his PhD dissertation paper entitled “Architectural Styles and the Design of Network-based Software Architecture”. There he described REST as
“Representational State Transfer (REST) architectural style for distributed hypermedia systems, ..”
So REST is the architectural style around which WWW is built.
The key constraints of REST are
- Client & Server – This separates the UI from data processing and storage.
- Stateless – This implies that each client request must contain all necessary information to process the request.No state is maintained by the server.This improves reliability as state of a request is not preserved and hence no need to recover in case of failure.This improves scalability taking away overhead of state management from server.
- Cached – Response for a particular request can be identified as cacheable or non-cacheable.If it is cacheable then client can reuse the response to the same request.This improves efficiency.
- Layered – This allows the system to be decomposed into hierarchy of layers where each layer depends on the service provided by the layers below and provides some service to the layers above in the hierarchy.This helps to reduce system complexity but adds to latency which can be balanced by caching.
- Uniform Interface – This implies loose coupling between services provided and their implementations so that they can evolve independently of each other.
Resource is the major abstraction in REST.A Resource can be document ,image or a service which is uniquely identified by it’s Uniform Resource Identifier(URI).Each resource has an associated sequence of bytes for it’s Representation and Representation Metadata describing the representation e.g. representation can be a document and it’s representation metadata might be content type of the document.
Now the obvious question how do we achieve the Uniform Interface?.This is provided by the Hypertext Transfer Protocol or HTTP.HTTP is the well established application level protocol for WWW and provides well defined operations and status codes.The listing below shows the HTTP methods and their correspondence with the CRUD operations.
|Method Name||Description||CRUD operation|
|GET||Retrieves representation of a resource||READ|
|POST||Submits data to be processed by a resource||UPDATE|
|PUT||Creates a new resource or representation||CREATE|
|DELETE||Deletes a resource||DELETE|
So how do we apply REST in terms of services.REST defines the way we human beings interact with the Web so if we apply the same style in defining the way programs interact over the Web we will be able to design RESTful services.
Let us proceed with the design considering a web application exposing services to maintain personal contacts where list of contacts or a single contact can be retrieved,new contacts can be added,existing can be updated and deleted.
- Identify the Resources – To identify the resources we need to focus on the entities in the problem domain i.e. Nouns.Here the two entities are
- Contacts – All contacts
- Contact – Individual contact present in the list.This is a part of Contacts itself.
- Design the URI
- Map with CRUD operations as per requirement
|HTTP Method||URI||Service Provided|
|GET||www.xyz.com/Contacts||View All Contacts|
|PUT||www.xyz.com/Contacts||Add new contact|
|GET||www.xyz.com/Contacts/100||Get details of contact with id=100|
|POST||www.xyz.com/Contacts/100||Update contact with id=100|
|DELETE||www.xyz.com/Contacts/100||Delete contact with id=100|
- The content type of the representation of these resources can be POX/JSON.
RPC Style Services
For the same application to design RPC style services the design approach will be different.We will be concentrating on the operations to be provided by the service i.e. actions or Verbs.
- Identify the operations in the service interface
- The URI can be designed as follows:
- Data format returned by or submitted to this URIs can be POX/JSON.
- RPC focuses on actions/verb while REST focuses on resources/entities/nouns.
- RPC defines an custom interface with operations and REST defines a resource with URI and actions are defined by uniform interface of HTTP.