随笔 - 41  文章 - 29  trackbacks - 0
<2008年11月>
2627282930311
2345678
9101112131415
16171819202122
23242526272829
30123456

常用链接

留言簿(5)

随笔分类(28)

随笔档案(23)

收藏夹(6)

Inside JVM

Java

java performance

Solr

搜索

  •  

最新评论

阅读排行榜

评论排行榜

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.
      ActionSQLHTTP
      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
    PerspectiveSOAPREST
    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.
posted on 2008-11-05 10:43 Justin Chen 阅读(2081) 评论(3)  编辑  收藏 所属分类: Rest

FeedBack:
# re: Creating Restful Web Service instead of SOAP web service 2008-11-05 10:44 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 Feng
about "Claimed benefits i am not quite sure -- Resource link":
suppose customer 123 has a order with orderID 456, then when /customer/123 will display the customer 123, including order 456, click through the order 456, 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 already have 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 121nazar@gmail.com
Hello!
This is gratefull example.
Could you please post src code fro this examples that will be gratefull?  回复  更多评论
  

只有注册用户登录后才能发表评论。


网站导航: