Creating Restful Web Service instead of SOAP web service-优快云博客

本文介绍了RESTful服务的基本概念，包括其架构风格、原则及其与SOAP服务的区别。REST将一切视为资源，并通过统一接口进行交互，使用标准HTTP方法实现资源操作。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

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.

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.
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 RES Tful 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.

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

RES Tful 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

Benefits for RES Tful web services
- Claimed benefits i like
  - More loose coupling
    RES Tful 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
    RES Tful 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
    RES Tful 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.
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":
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...