Comparison and distinction between SOAP Webserivce and RESTful WebService

 ) is a  XML -based protocol that can be used in conjunction with many existing Internet protocols and formats, including Hypertext transfer protocols (http ), Simple Mail Transfer Protocol (smtp ), Multipurpose Internet Mail Expansion Protocol (mime ", based on the "universal" transport protocol is an advantage of  soap . It also supports a large number of applications, from the messaging system to Remote procedure calls (remotes Procedure call,rpc). SOAP provides a series of criteria, such as WSRM (ws-reliable Messaging) formal contract to ensure reliability and security, ensuring asynchronous processing and calling , Standard .

 

SOAP protocol is a complex, heavyweight protocol , now with the rise of Web2.0, representational state transfer (representational Transfer,rest) is gradually becoming a popular architectural style. rest is one The Lightweight Web service Architecture style , which implements and operates more succinctly than soap and XML-RPC, can The is implemented entirely through the HTTP protocol , can also take advantage of cache caches to improve responsiveness, performance, efficiency, and ease of use over the SOAP protocol . The rest schema's operations on resources, including obtaining, creating, modifying, and deleting resources correspond exactly to the get, POST, put, and Delete methods provided by the HTTP protocol, which is designed and developed for network applications, reduce the complexity of development and increase the scalability of your system . The rest architecture is especially (Create, read, update, delete, creation, read, updates, remove) operations.

The rest-based software architecture style (software Architecture style) is called a resource-oriented architecture (resource-oriented Architecture,roa). The software, architecture, which is designed in accordance with the rest principle, is often referred to as "restful" (restful), which is described in this article as a RESTful Web service to make it easier to differentiate from soap-based Web services.

The server side uses the Java EE, the client uses the JSP, the Flex, the JavaFX, the air and so on can call the servlet directly, other implementation technology basically cannot call directly, but regardless of that kind of client, for SOAP-based Web service or based on restful Web services are supported, such as Ajax XMLHttpRequest, Flex Httpservice, and so on. As shown in the following:

Client and server-side mode of communication

HTTP request should essentially be a secure call, that is: call does not have any side effects, does not cause the server side state changes. For a server, the client makes N-times a GET, haed call to a URI, and its state is the same as not making a call, and no change will occur.

The put, delte invocation of HTTP has a power-reference equality feature, that is, the client makes N-times a PUT, Delte call to a URI, and the effect is the same as the call to do it once. The GET and HEAD methods of HTTP also have power-reference equality attributes.

HTTP these standard methods guarantee in principle that your distributed system has these features to help build a more robust distributed system.

Safety control

To illustrate the problem, based on the above online user management system, we have given the following scenarios:

Referring to the use case diagram we gave at the outset, for client Client2, we only want it to access the user and user List resources in a read-only manner, and Client1 has all the permissions to access all the resources.

How do you do this security control?

The common practice is that all HTTP requests made from client Client2 are proxied (proxy server). The proxy server formulates a security policy: all requests that go through the agent's access to the user and user List resources have read access only, that is, allow get/head operations, and Put/delte like write permissions are not allowed.

For REST, let's see how this security policy is deployed. As shown in the following:

Figure 4. REST and Proxy server (proxies Servers)

The implementation of a generic proxy server determines the security legitimacy of an HTTP request based on a two-tuple (URI, HTTP Method).

When a request similar to (Http://localhost:8182/v1/users/{username},delete) is found, it is rejected.

For SOAP, if we want to use the existing proxy server for security control, it will be more embarrassing, such as:

Figure 5. SOAP and proxy servers (proxy Servers)

All SOAP messages go through a proxy server and see only (
Http://localhost:8182/v1/soap/servlet/messagerouter
, HTTP POST), if the proxy server wants to know what the current HTTP request specifically does, it must decode the soap's message body, which means that the proxy server for the third party needs to understand the current SOAP message semantics, and this soap The tight coupling between the application and the proxy server is unreasonable.

About caching

As we all know, for network-based distributed applications, network transmission is an important factor affecting application performance. How to use caching to save the overhead of network transport is an issue that every developer who constructs a distributed network application must consider.

The HTTP protocol conditional HTTP GET request (Conditional get) is designed to save the overhead of network transport between the client and the server, which also provides the possibility for the client to implement the Cache mechanism, including any proxy between the client and the server. The HTTP protocol implements a conditional get request through the HTTP HEADER domain: If-modified-since/last-modified,if-none-match/etag.

REST applications can fully exploit the HTTP Protocol's ability to support caching. When the client first sends an HTTP GET request to the server for content, the content may be cached by the cache server. The next time the client requests the same resource, the cache can give a direct response without requiring the remote server to obtain it. And all of this is transparent to the client.

Figure 6. REST and cache servers (cache server)

And for SOAP, what's the situation?

Soap using the HTTP protocol, because its design in principle does not emphasize the same way as REST, is consistent with how the WEB works, so it is difficult to make full use of the HTTP itself cache capability based on SOAP applications, Figure 7. SOAP and cache servers (cache server)

Two factors determine that the caching mechanism for SOAP-based applications is far more complex than REST:

First, all the SOAP messages that go through the cache server are always HTTP POST, and if the cache server does not decode the SOAP message body, it cannot know if the HTTP request is to obtain data from the server.

Second, the URI used by the SOAP message always points to the server of soap, as in the example in this article
Http://localhost:8182/v1/soap/servlet/messagerouter
, which does not express the actual resource URI, the result is that the cache server does not know that the resource is being requested, not to mention cache processing.

About connectivity

In a pure SOAP application, a URI is inherently meaningless except to indicate a SOAP server. Unlike REST, SOAP method calls cannot be driven by URIs. For example, in our example, when we pass

After the Getuserlist SOAP message obtains all the user lists, it is still unable to get a specific user information through the existing information. The only way to do this is through the instructions of the WSDL, obtained by calling Getuserbyname, Getuserlist and getuserbyname are isolated from each other.

And for REST, the situation is completely different: by
Http://localhost:8182/v1/users
The URI obtains a list of users and then passes the LINK property provided in the user list, for example
<link>http://localhost:8182/v1/users/tester</link>
Get user information for tester users. This works very much like when you click on a hyperlink on a page of your browser, and your browser automatically directs you to the page you want to visit, without relying on any third party information.

REST of the system built by the system is stronger than SOAP, which can be reflected in its unified interface abstraction, Proxy server support, caching server support and many other aspects, and the maturity of SOAP can be provided to the multi-development language, multi-transmission mode, for the security of high-demand interface design convenience.