SOAP vs REST

Soap vs. rest is a pseudo proposition, and it is not appropriate to compare them directly, because soap (Simple Object Access Protocol) is a protocol, and rest (representational state transfer) is an architectural style.

Protocol and architecture are two completely different levels of things, the protocol is the information exchange in the computer network rules, standards and conventions, which tend to the technical details and the bottom, the architecture is at the system level of the benchmark, universality and principles, which are biased towards abstraction and the top layer. A protocol can be used in different architectures, and multiple protocols can be used during the construction of the architecture. But I'll compare them both, because they can all be used to build a web Service. The greatest role of WEB service is its interoperability, which is independent of platform and language, allowing different applications to invoke each other.

In layman's words, Web service sweeps away the barriers of remote objects or method calls, and it is a bridge for communicating information between different applications or servers.

1. Basic Concepts

In my two previous articles, Soap introduction and rest, I've explained some of the concepts and origins of soap and rest in more detail. If you're not sure about the concept of both, read these 2 articles first.

Soap

Soap can be seen as an upgraded version of XML-PRC, a lightweight, simple XML-based protocol that allows applications to exchange information over HTTP or other transport protocols, and SOAP is the protocol used to access Web service.

REST

Rest is a price style, not a standard. Rest defines a set of architectural principles that enable CRUD operations on resources with the standard method of HTTP (post,get,put,delete).

Comparison of 2.SOAP and rest

A SOAP client is like a desktop application, and it is tightly coupled to the server.

A common, strict contract is maintained between the SOAP client and the server. When the client's invocation model changes, the server needs to change the contract to accommodate the client, and when the service-side contract changes, the SOAP client must either manually or automatically update its contract, otherwise the client and the server will not be able to communicate.

A rest client is more like a browser application, and it is loosely coupled to the server.

The rest server provides a unified approach to each resource, which is based on the standard method of HTTP and uses a common URI. Similarly, the rest client operates the server-side resources through HTTP standard methods and URIs.

Because client access is highly consistent with the way the rest service provides operations, and all follow the standards of HTTP, the client and server calls do not need to change at all when the service-side or client-side business logic changes.

Lists the invocation methods for SOAP Web service and RESTful Web service, respectively

From another point of view, the SOAP Web service exposes Operations (operation), each with a different logic.
A RESTful Web service exposes a resource (Resource), and each resource can support a curd operation.

The following is a list of several differences between SOAP Web service and Rest Web service:

• Communication protocol: SOAP supports the main communication protocol, in addition to supporting the HTTP protocol, it also supports HTTPS, TCP, UDP and other protocols, it is protocol neutrality. Rest supports only the HTTP protocol and HTTPS protocol.
• Data format: SOAP supports XML data format only, because the SOAP message format is XML. Rest supports a variety of data formats, which support XML, JSON, HTML, and txt.
• Security: SOAP supports SSL and ws-security. Rest only supports point-to-point SSL security.
• Request method: The request method of SOAP only supports HTTP POST. Rest requests support the standard method of HTTP, for example: Get/post/put/delete.
• Data caching: SOAP-based data reads cannot be cached. Rest-based data reads can be cached, and rest has better performance and scalability than soap for data reading.
  The cache here refers to the client's cache, on the server side of course we can use the session to achieve the purpose of caching, but this will add to the burden of servers.
• State management: Because SOAP supports different communication protocols, WS built on HTTP or HTTPS can be considered stateless; In addition, we can have a stateful task. Rest can only support HTTP and HTTPS protocols, so its resource management is stateless.
• Acid transaction: SOAP supports the acid characteristics of a transaction. While rest supports transactions, it does not fully support the acid characteristics of transactions.
  Fortunately, the ACID transaction is a database transaction, and in the Internet we don't have much of a scene

This article was reproduced from: Http://blog.64cm.com/post/2015/04/06/SOAP-vs-REST

SOAP vs REST