Comparison of differences between rest and soap Web service

Reproduced in this article from someone else's blog, ArcGIS Server has introduced support for soap and rest two types of interfaces (which may not be accurate with the interface type), and this article is a very clear comparison between soap and rest!

/////////////////////////////////////////////////////////////////////////////////////////////////////////////// /////////////
Rest seems to rise up overnight, and this may cause some controversy, and opponents can say that rest is the principle of the birth of the web even when the advent of HTTP was born. But there is no doubt that rest is more favored in Web Service APIs, such as Google and Yahoo!, which are the same features that the Internet giants publish, so is it possible to say that RPC is fading overnight?

In a small article on a job to discuss the whole set of RPC principles, is undoubtedly too large, and RPC in the Web service field of application has no xml-rpc and the extension of soap. The only important thing in principle is that the function call and return of the traditional program is replaced by the request and answer in RPC. In that case, it might be logical to elaborate on soap before discussing rest.

What is SOAP?

SOAP (Simple Object Access Protocol), as its name implies, is a tightly defined information exchange protocol used to encapsulate remote calls and returns in a Web service into machine-readable formatted data. In fact, SOAP data uses an XML data format that defines a complex set of tags that describe the remote procedures, parameters, return values, error messages, and so forth of the call. And with the need to grow, and not to increase the protocol to support security, this makes soap unusually large, deviating from the simple intention. On the other hand, each server can launch its own API based on this protocol, even if the services they provide are similar, the defined APIs are different, which leads to the creation of WSDL. WSDL (Web service Description Language) also follows the XML format to describe which server provides what services, how to find it, and what interface specifications the service uses, in short, service discovery. Now, the process of using the Web service becomes, obtains the WSDL description of the service, constructs a formatted SOAP request based on the WSDL to send to the server, then receives an answer in the same soap format, and finally decodes the data based on the previous WSDL. In most cases, the request and the reply are transmitted using the HTTP protocol, then the send request uses the HTTP POST method.

What is rest?

The REST (representational state transfort) Form should be expressed as the client through the application of resources to achieve the transformation of the status, in this perspective the system can be regarded as a virtual state machine. Throw away R. The obscure theory in Dr. T. Fielding's thesis does not say that rest should satisfy such a feature:

1) client and server structure;

2) The connection protocol has no State;

3) Ability to use the cache mechanism to improve performance;

4) hierarchical system;

5) on-demand code.

After all, rest is just an architectural style, not a protocol or a standard. But this new style (perhaps already has a long history?) The impact of the existing SOAP-based Web service is also revolutionary, because it is resource-oriented, and even services are abstracted as resources because it is tightly bound to HTTP because it has a stateless server.

The difference between rest and soap

Because SOAP does not assume a lower-level protocol for transmitting data, it must be designed to run on a variety of protocols. Even though the vast majority of soap runs on HTTP and uses the URI to identify the service, SOAP simply sends the request using the Post method, identifying the portal of the service with a unique URI.

As an example of a library online query management system, the service provider must provide an internal identifier for each book, and then perhaps define a listbooks action to return a series of books, a getbook operation to return the specified book, A createbook operation to add new books to the database, a deletebook operation to delete obsolete books, each with its own parameters, especially a book that identifies the operation with an internal identity. The criticism of this design is that the Deletebook operation is also sent using the Post method, whereas the HTTP protocol has a more and more logical Delete method available. Rest is designed in such a way that rest assigns a unique URI to each resource (here is a book), while the 4 methods of getting, POST, PUT, and delete in HTTP visually represent the acquisition, creation, updating, and deletion of books. At the same time the book collection is also a book with a different resources, if using/books to represent the book list,/books/id to represent the ID of the book, then the/books of the Get operation represents the return of the entire book list, the/books/ The delete operation of the ID represents the deletion of the specified book, and so on.

Benefits of rest

Rest is simple and intuitive, using the HTTP protocol to the limit, and under the guidance of this idea, it even uses the header information of the HTTP request to indicate the resource's representation (if a resource has multiple forms, such as human-friendly pages or machine-readable data?). ), using an HTTP error mechanism to return an error accessing the resource. The immediate benefit is that the cost of the build is reduced, such as using URIs to locate each resource can take advantage of a common, proven technology without having to develop a set of resource access mechanisms on the server side. You can also specify access to resources by simply configuring the server, such as by prohibiting non-get access to make the resource read-only.

Server stateless brings additional benefits because each request contains all the information needed to respond, all state information is stored on the client, and the server's memory is freed from the huge state information. And now even a sudden crash of a server has a negligible impact on the customer, because another server can immediately replace its location without having to consider recovering state information. More caches are also possible, and requests to the same URI can cause a completely different response because the server is stateful.

The overall result is that the network's fault tolerance and ductility are enhanced, which is originally the original purpose of web design, the increasingly complex and customized web to destroy them, and now rest is back to basics, trying to bring Web service back to simple principles.

is rest omnipotent?

But is rest the almighty? Stateless brings a huge advantage, and it also brings problems that are difficult to solve, such as how to empower a specific user to use a service? How do I verify a user's identity? If you persist the server stateless, that is, do not log the user logon status, it is bound to require that each service request contains the full user identity and authentication information. In this case, how to avoid the risk of recognition? How to avoid user information leakage? In fact, building a rest-attached security mechanism is already under discussion, and the result is nothing more than another soap: complex requirements that devastate ease of use.

Rest supporters claim that rest requests and response data are simple to read, while SOAP requires a tedious package, and even so, soap is still unable to achieve interface consistency, and the different vendors have their own interfaces, while rest uses only HTTP-defined methods and is therefore generic. Is that really the case? Imagine a service that uses rest to achieve two sums, and if, as suggested, the service (here is the addition) as a resource, the parameter (here is two addend) as the parameter of the request, the result is returned in XML or JSON syntax, is it easier to use than soap? The generic interface still cannot be reached because the name of the resource, the name of the parameter, and the format of the result are still defined by the service provider.

To solve this problem, WASL (Web application Description Language) is proposed to describe the rest interface. Wadl is like the rest version of WSDL, where the shadow of soap is everywhere as rest is applied to complex fields.

Resource-oriented and transaction-oriented (it is very obvious that the trial scope of rest is explained, request map data can be considered primarily to request a special resource)

Rest is used in resource-oriented applications, but not in transaction-oriented applications. Resource-oriented application operation is simple, nothing but create, read, change, delete a few items, but the transaction-oriented application does not allow users to manipulate resources directly, the user only need to submit a transaction description requirements to the system, and then wait for the completion of the transaction, such as an online banking users do not directly modify the account and deposit, Instead, submit a transaction to tell the bank to transfer the money itself. If you consider such a service as a resource, by sending a POST request to the resource to complete the transaction, it is just a copy of the soap, either this, or by putting to create the transaction, all change the state of the system (the resource itself has not changed, here is to change the user's balance), Clearly violates the intuitive purpose of rest.

In fact, the rest API provided by some Web service providers is only the rest of the shell, the transfer of requests and responses is completely simplified soap, this new bottle of old wine has only deepened the standard differences. In the final analysis, rest cannot simply solve some applications, so we can only see the reincarnated of soap under the rest shell. No technology can solve all problems once and for all, and it is sufficient to gracefully solve the problem in the field under the predetermined constraints. The introduction of a new technology has always attracted countless follow-up and flattery, only when the dust settles down to get a fair evaluation.