走自己的路

路漫漫其修远兮,吾将上下而求索

  BlogJava :: 首页 :: 新随笔 :: 联系 :: 聚合  :: 管理 ::
  50 随笔 :: 4 文章 :: 118 评论 :: 0 Trackbacks
 

Rest and Restful web services

There are currently two schools of thought in developing web services: the traditional, standards-based approach (SOAP) and conceptually simpler and the trendier new kid on the block (REST). The origin of the term "REST" comes from the famous thesis from Roy Fielding describing the concept of Representative State Transfer (REST). REST is an architectural style that can be summed up as four verbs (GET, POST, PUT, and DELETE from HTTP 1.1) and the nouns, which are the resources available on the network (referenced in the URI). The verbs have the following operational equivalents:

HTTP     CRUD Equivalent

==============================

GET      read

POST     create,update,delete

PUT      create,update

DELETE   delete

The emergence of the RESTful style of web services was a reaction to the more heavy-weight SOAP-based standards. In RESTful web services, the emphasis is on simple point-to-point communication over HTTP using plain old XML (POX) or JSON.

Java API for RESTful Web Services specification is in final state, JAX-RS is an annotation-based API for implementing RESTful web services, based on HTTP. In addition to the Sun-provided reference implementation, Jersey, other implementations are available (in various stages of completion): as part of the popular Restlet framework, the JBoss RESTeasy project , and as part of the Apache CXF web services stack.

Rest vs SOAP:

Representation

A REST-style web service might be every bit as subtle and complicated as a SOAP-based service. The RESTful approach tries to simplify matters by taking what HTTP, with its MIME type system, already offers: built-in CRUD operations, uniformly identifiable resources, and typed representations that can capture a resource's state. The key to the REST methodology is to write Web services using a representation that is already well known and widely used: the URI.

Complexity

REST as a design philosophy tries to isolate application complexity at the endpoints, that is, at the client and at the service. A service may require lots of logic and computation to maintain resources and to generate adequate representation of resources—for instance, large and subtly formatted XML documents—and a client may require significant XML processing to extract the desired information from the XML representations transferred from the service to the client.

Bandwidth

RESTful approach keeps the complexity out of the transport level, as a resource representation is transferred to the client as the body of an HTTP response message. By contrast, a SOAP-based service inevitably complicates the transport level because a SOAP message is encapsulated as the body of a transport message; for instance, an HTTP or SMTP message. SOAP requires messages within messages, whereas REST does not.

Performance

SOAP uses XML generally bloats your messages quite a bit.

Something like POX or JSON would be more compact and maybe faster to serialize / deserialize.

Payloads of SOAP are significantly larger which are slower to assemble, transport, parse, validate and process.

Security

A typical SOAP request will use POST to communicate with a given service. And without looking into the SOAP envelope, there's no way to know whether that request simply wants to query data or delete entire tables from the database

As for authentication and authorization, SOAP places the burden in the hands of the application developer. The REST methodology instead takes into account the fact that Web servers already have support for these tasks.

Domain Design

SOAP services defined in Web Services Description Language (WSDL) emphasize contracts and actions. In contrast, REST focuses on direct addressing and manipulation of resources, which is more compatible with the domain-driven approach.

Defects

l           There is less definition of interface, especially the method interface

l           Hard to make strongly typed objects to work with it in server side code  

l           Only works over HTTP, but SOAP can work on HTTP, FTP, MIME, JMS, SMTP and etc

l           Calls to REST are restricted by HTTP Verbs (GET, POST, PUT, DELETE.. etc)

l           No automatic xml schema validation

l           Less SOA-style than SOAP

l           Developer has less control on security than SOAP, SOAP has ws-*(ws-security, ws-trust, ws-policy and etc), SAML, XACML and etc

l           Routing is network-controlled, but SOAP can make client to control routing explicitly through SOAP headers, WS-Addressing and etc

Implementation

How to implement Restful web services, there are three kinds of methods recently:

  • Make use of provider and dispatch twins of SOAP-based web service
  • Implement Restful HTTPServlets
  • JAX-RS, annotation-based implementation



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


网站导航: