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
- 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 |
- 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.
- 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 阅读(2092)
评论(3) 编辑 收藏 所属分类:
Rest