Creating Restful Web Service instead of SOAP web service

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

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.
     ActionSQLHTTP CreateInsertPUTReadSelectGETUpdateUpdatePOSTDeleteDeleteDELETE
     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
   PerspectiveSOAPREST Architecture StyleActivity-Centric StyleResource-Centric StyleMethodEncapsulated within the SOAP messageKnown from HTTP methodTargetEncapsulated within the SOAP messageKnown from URIFormatSOAP message with lots of extra definitionsLightweight,not a lot of extra xml markupToolsYou need tools, such as AxisEasy 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.

Feedback

# re: Creating Restful Web Service instead of SOAP web service  回复  更多评论  

2008-11-05 10:44 by Justin Chen

BTW, the following are some related articles-
Building Web Services the REST Way
An introduction on REST
Representational State Transfer Wiki
A Brief Introduction to REST
Addressing Doubts about REST
REST Anti-Patterns

I will talk about more on how to build REST web service in next time.

# re: Creating Restful Web Service instead of SOAP web service[未登录]  回复  更多评论  

2008-12-09 23:49 by Feng

about "Claimed benefits i am not quite sure -- Resource link":
supposecustomer 123 has a order with orderID 456, then when /customer/123 willdisplay the customer 123, including order 456, click through the order456, will lead you to /order/456.

I am not quite sure about"Easy for API maintaining and backward compatibility" /customer/ =getCustomer(int id), to me, it is still api-ish, if consumer alreadyhave code consume your webservice, you can not change it freely.

Just some thoughts...

# re: Creating Restful Web Service instead of SOAP web service  回复  更多评论  

2009-03-27 00:16 by [e-mail]

Hello!
This is gratefull example.
Could you please post src code fro this examples that will be gratefull?