Recently, Rest architecture style or Restful web service is a hot topic for SOA, web service design and architecture style. This message gives us a brief introduction on Restful web service (All of these information comes from internet and i just re-organized them) and some thoughts on how can we apply this new architecture pattern into our common service services.

1. Representation State Transfer

   • The Web is comprised of resources. A resource is any item of interest. For example, the Boeing Aircraft Corp may define a 747 resource. Clients may access that resource with this URL: http://www.boeing.com/aircraft/747 The Client references a Web resource using a URL. A representation of the resource is returned (for example, an HTML document). The representation (e.g., Boeing747.html) places the client application in a state. The result of the client traversing a hyperlink in Boeing747.html is another resource is accessed. The new representation places the client application into yet another state. Thus, the client application changes (transfers) state with each resource representation—> Representation State Transfer!
     
   • From an architecture style perspective – REST is a key design idiom that embraces a stateless client-server architecture in which the web services are viewed as resources and can be identified by their URLs. Web service clients that want to use these resources access a particular representation by transferring application content using a small globally defined set of remote methods that describe the action to be performed on the resource.
     

2. The Principles for REST

   • Everything is resource. And every resource has an ID.
     An important concept in REST is the existence of resources (sources of specific information), each of which is referenced with a global identifier (e.g., a URI in HTTP). Application state and functionality are abstracted into resources. Every resource is uniquely addressable using a universal syntax for use in hypermedia links. The following are some examples for resource URI.
     http://users.starcite.com/users (a list of all users)
     http://users.starcite.com/users/001 (details for user 001)
     http://users.starcite.com/users/002 (details for user 002)
     
   • Link resources together Next principle is “Hypermedia as the engine of application state”. Consider the following made-up XML fragment:

             <order self="http://users.starcite.com/users/1234"> 
     
             <name>PWC</name> 
     
             <permission ref="http://users.starcite.com/permission/4554"> 
     
             </permission><group ref="http://users.starcite.com/group/132">  
     
             </group></order> 
     
             

   • If you look at the links in this document, you can easily imagine how an application that has retrieved it can “follow” the links to retrieve more information. The beauty of the link approach using URIs is that the links can point to resources that are provided by a different application, a different server, or even a different company on another continent — because the naming scheme is a global standard, all of the resources that make up the Web can be linked to each other.
   • Use standard methods
     All resources share a uniform interface for the transfer of state between client and resource. In an OO approach, you may have lots of operations handling an object, such as creating object, updating Object, getting Objects, and deleting object. In a RESTful HTTP approach, you would have to get by with the generic interface that makes up the HTTP application protocol.HTTP calls these verbs.
     

     Action	SQL	HTTP
     Create	Insert	PUT
     Read	Select	GET
     Update	Update	POST
     Delete	Delete	DELETE

     
     For clients to be able to interact with your resources, they should implement the default application protocol (HTTP) correctly, i.e. make use of the standard methods GET, PUT, POST, DELETE.
   • Resources with multiple representations
     Any resource is able to have multiple representation, it could be HTML or XML or whatever you defined. The client will decide which format it needs. A client that knows how to handle a particular data format can interact with all resources that can provide a representation in this format.
3. RESTful web service v.s. SOAP based web service
   

   Perspective	SOAP	REST
   Architecture Style	Activity-Centric Style	Resource-Centric Style
   Method	Encapsulated within the SOAP message	Known from HTTP method
   Target	Encapsulated within the SOAP message	Known from URI
   Format	SOAP message with lots of extra definitions	Lightweight,not a lot of extra xml markup
   Tools	You need tools, such as Axis	Easy to build, because it is pure HTML or XML

4. Benefits for RESTful web services
   • Claimed benefits i like
     • More loose coupling
       RESTful web service uses standard HTTP method (GET, POST, PUT, DELETE) and unique URI identity, so client and server side are totally decoupled with one exception which they have to have the same understanding on data. Comparing to SOAP web services, both sides have to obey the same WSDL definition.
     • Lightweight
       RESTful web services don’t request complex extra encapsulation for API and input/output. The response is only one of the representation of resource.
     • Easy for developing
       All resources share a set of uniform interfaces, normally HTTP Methods (even it doesn’t have to). And the most common implementation solution is HTTP+XML or HTTP+JSON or HTTP+HTML
     • Easy for API maintaining and backward compatibility
       RESTful web services reuse the standard HTTP method. Comparing to SOAP, actually, we don’t have to consider the API versioning and backward compatibility too much because there are no API definition any more.
     • Easy for testing/human understandable
       The request or response (XML/JSON/HTML etc) for the service can be read by browser. Comparing to SOAP message, they are easier to understand.
   • Claimed benefits i am not quite sure
     • Resource link
       The fact that the server side provides a set of links to the client (the service consumer) enables the client to move the application from one state to the next by following a link. But i am not sure, how can we use this functionality.
     • Cache
       Provides improved response time and reduced server load due to its support for the caching of representations. REST folks believe the application can cache the resource because each resource has unique ID.
5. Creating Restful web services for our common services
   As we all know, we are developing/refactoring common services for the common business components. In current phase, we are using SOAP based web services. It already caused some issues, such as API compatibility issue and how to test them effectively.
   Restful web service may give us an alternative solution for web service. And most of our common services actually are natively resource-oriented, such as User, Vendor, RFP, Meeting etc.
   Of course, Restful web service is not the one to solve all issues. It has own application context. Let’s think about if it will be a better choice for our web services.