Simple Object Access Protocol (SOAP) is an XML-based protocol that can be used in conjunction with many existing Internet protocols and formats, including hypertext Transmission protocol (HTTP), Simple Mail Transfer Protocol (SMTP), Multipurpose Internet Mail Extension Protocol (MIME), based on “universal” transmission protocol is an advantage of SOAP. It also supports a large number of applications ranging from messaging systems to Remote Procedure Call (RPC). SOAP provides a series of standards, such as WSRM (WS-Reliable Messaging) formal contract to ensure reliability and security, and to ensure asynchronous processing and invocation; standards such as WS-Security, WS-Transactions and WS-Coordination provide contextual information and Dialogue state management.
Relatively speaking, the SOAP protocol is a complex and heavyweight protocol. With the rise of Web 2.0, Representational State Transfer (REST) has gradually become a popular architectural style. REST is a lightweight Web Service architecture style. Its implementation and operation are more concise than SOAP and XML-RPC. It can be implemented completely through the HTTP protocol. It can also use the cache to improve response speed, performance, efficiency and ease of use. It is superior to SOAP protocol in terms of performance. The operations of the REST architecture on resources, including obtaining, creating, modifying, and deleting resources, correspond to the GET, POST, PUT and DELETE methods provided by the HTTP protocol. This design and development method for network applications can reduce the complexity of development. Improve the scalability of the system. The REST architecture is especially suitable for completely stateless CRUD (Create, Read, Update, Delete, create, read, update, delete) operations.
REST-based Software Architecture Style (Software Architecture Style) is called Resource-oriented Architecture (ROA). The software and architecture designed according to REST principles are usually called “RESTful” (RESTful). In this article, they are called RESTful Web services in order to distinguish them from SOAP-based Web services.
The server uses J2EE, and the client uses JSP, Flex, JavaFX, AIR, etc. to directly call Servlet. Basically, other implementation technologies cannot be used directly. But no matter what kind of client, it supports SOAP-based Web services or RESTful Web services, such as AJAX’s XMLHttpRequest, Flex’s HTTPService, etc. As shown in the figure below:
The communication method between client and server
HTTP GET and HEAD requests should essentially be safe calls, namely: GET, The HEAD call will not have any side effects and will not cause changes to the server-side state. For the server, if the client makes n times of GET and HAED calls to a certain URI, the status is the same as that of no calls, and no changes will occur.
HTTP PUT and DELTE calls have the characteristics of power and exponential equality, that is: the client makes n times PUT and DELTE calls to a certain URI, and The effect is the same as making a call. HTTP’s GET and HEAD methods also have the characteristics of idempotent equality.
HTTP These standard methods guarantee in principle that your distributed system has these characteristics to help build a more robust distributed system.
Security control span>
To illustrate the problem, based on the above online user management system, we give the following scenarios:
Refer to the use case diagram we gave at the beginning. For the client Client2, we only hope that it can access the User and User List resources in a read-only manner, and Client1 has all the permissions to access all resources.
How to do this safely control?
The common practice is: all HTTP requests sent from the client Client2 go through the Proxy Server. The proxy server formulates a security policy: all requests to access User and User List resources through the proxy only have read permissions, that is, GET/HEAD operations are allowed, while PUT/DELTE with write permissions is not allowed.
If for REST, let’s look at how such a security policy is deployed. As shown in the figure below:
Figure 4. REST and proxy server (Proxy Servers)
The implementation of general proxy server is based on (URI, HTTP Method) two yuan Group to determine the security and legitimacy of HTTP requests.
When a request similar to (http://localhost:8182/v1/users/{username}, DELETE) is found, it will be rejected.
For SOAP, if we want to use the existing proxy server for security control, it will be embarrassing, as shown below:
Figure 5. SOAP and Proxy Servers
< img src="/wp-content/uploadshttp:/img.voidcn.com/vcimg/static/loading.png" alt="" style="font-size:18px">
All SOAP messages go through the proxy server and can only be seen (
http://localhost:8182/v1/soap/servlet/messagerouter
, HTTP POST) such information If the proxy server wants to know what the current HTTP request is doing, it must decode the SOAP message body. In this case, it means that the third-party proxy server needs to understand the current SOAP message semantics, and this SOAP application and proxy The tightly coupled relationship between servers is unreasonable.
About cache span>
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 cost of network transmission is a question that every developer who builds distributed network applications must consider.
The conditional HTTP GET request (Conditional GET) of the HTTP protocol is designed to save the overhead caused by the network transmission between the client and the server. It 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 conditional GET requests through the HTTP HEADER domain: If-Modified-Since/Last-Modified, If-None-Match/ETag.
REST applications can fully tap the ability of the HTTP protocol to support caching. When the client sends an HTTP GET request to the server to obtain the content for the first time, the content may be cached by the Cache Server. When the client requests the same resource next time, the cache can give a response directly without requesting the remote server to obtain it. And all of this is transparent to the client.
Figure 6. REST and Cache Server< /span>
But what about SOAP?
SOAP that uses the HTTP protocol, because its design principle does not emphasize consistency with the way the Web works like REST, so SOAP-based applications are very It is difficult to give full play to the caching capabilities of HTTP itself, Figure 7. SOAP and Cache Server
Two factors determine that the caching mechanism based on SOAP applications is far more complex than REST:
, First, all SOAP messages that pass through the cache server are always HTTP POST, if the cache server does not decode the SOAP message body, it cannot know whether the HTTP request is to obtain data from the server.
Second, the URI used in SOAP messages always points to the SOAP server, as in the example in this article.
http://localhost:8182/v1/soap/servlet/messagerouter
, this does not Expressing the real resource URI, the result is that the cache server does not know which resource is being requested, let alone caching.
About connectivity< /span>
In a pure SOAP application, the URI is essentially meaningless except for indicating the SOAP server. Unlike REST, SOAP method calls cannot be driven by URIs. For example, in our example, after we get all the user lists through the getUserList SOAP message, we still cannot get a specific user information through the existing information . The only way is to get it by calling getUserByName as indicated by WSDL. GetUserList and getUserByName are isolated from each other.
For REST, the situation is completely different:
Passhttp://localhost:8182/v1/usersURI Get the user list, and then pass the LINK attribute provided in the user list, such as
http://localhost:8182/v1/ users/tester Get user information of tester users. This way of working is very similar to when you click a hyperlink on a certain page of the browser, and the browser will automatically be directed to the page you want to visit, without relying on any third-party information.
The system built by REST has stronger system scalability than SOAP, which can be reflected in its unified interface Abstraction, proxy server support, cache server support and many other aspects, and the maturity of SOAP can bring convenience to the interface design that needs to provide multiple development languages, multiple transmission methods, and high security requirements.