Comparison between rest WebService and soap WebService

In
Basic SOA technology implementation
WebService occupies a very important position.
The first idea of WebService is
Soap messages interact with each other over various transmission protocols. In recent years
The idea of rest is accompanied
SOA is gradually accepted, and major websites are continuously open
The API is provided to developers, which has aroused
REST style
WebService boom.

Soap

What is
Soap, I don't want to say much,
Google is full of eyes. Actually
Soap was initially targeted
RPC is a Simple Object Access Protocol that is lightweight. As an application protocol, multiple transmission protocols can be used to transmit messages (
HTTP, SMTP, etc ). However
Soap
The wide application of WebService and the increasing addition of additional content make developers feel that
Soap is very heavy and has a high usage threshold. In
In the subsequent development of soap,
WS-* The establishment of a series of protocols has increased
The maturity of Soap also gives
Soap adds burden.

Rest

Rest is not a protocol or a standard,
The original design intention of the HTTP protocol is explained in
Nowadays, HTTP is widely used as a transmission protocol, rather than the application protocol that was previously considered by designers.
Soap type
WebService is the best example,
The SOAP message simply refers
The HTTP protocol is used as the message bearer, so that
Parameters (such as encoding and error codes) in the HTTP protocol are ignored. In fact, the most lightweight application protocol is
HTTP protocol.
HTTP Abstraction
Get, post, put, and delete are like the most basic addition, deletion, modification, and query operations in the database, while various resources on the Internet are like records in the database (which may not be very good ), operations on various resources can always be abstracted into these four basic operations. After the resource locating rules are defined, operations on resources pass the standard
HTTP can be implemented, and developers will also benefit from this lightweight protocol.

The idea of rest comes down to the following key points:

1. Resource-Oriented Interface Design

All interface designs are designed for resources, which is similar to our object-oriented and process-oriented design differences. However, the operating entities on the network are regarded as resources.
The URI design also reflects the resource positioning design. Some websites will be mentioned later
API design
The rest design is actually
A mixture of RPC-REST, not
The idea of rest.

2. Abstract operations-based
Crud

This is simple,
In HTTP
Get, put, post, and delete correspond
Read, update, create, and delete operations. If they are just operations on resources, it is sufficient to abstract them into these four operations. But for some complex business service interface designs, this abstraction may not be sufficient. In fact, this is also
This problem is exposed in API design.
Rest design, then the applicable environment will have restrictions, rather than the universal.

3.
HTTP is the application protocol rather than the transmission protocol.

This is in
API analysis is clearly reflected. In fact, some websites have already arrived.
On the old road of soap, say yes
The Concept Design of rest is actually a set of private
The SOAP protocol.
Rest-style Customization
SOAP protocol.

4. Stateless, self-contained

This is not just
For rest, the interface design must be able to achieve this. It is also the most basic guarantee for scalability and efficiency.
Soap
The same is true for WebService.

Rest vs soap

Maturity:

Although soap has evolved from its original intention to the present, the release and calling of services in heterogeneous environments, as well as vendor support have all reached a relatively mature level. Different platforms and development languages
Soap for Interaction
Web services can communicate well (in some complex and special parameters and returned object parsing, the Protocol does not have very detailed provisions, resulting in partial correction)

Rest many large foreign websites have released their own development
API, many of which provide
Soap and
Two types of rest
Web service.
Rest-style usage is higher
Soap. However
Rest is only based on
Therefore
All rest implementations have their own set. We will discuss
The rest API style. It is precisely because of their respective implementations that the performance and availability will be significantly higher
Released by soap
Web service, but the unified and general aspects are far behind
Soap. Because of
SP usually focuses on this website
API development, so the general requirements are not high.

Because it is not similar
Soap authoritative protocol as a specification,
The various rest protocols can only be regarded as private protocols.
The concept of rest, but there are too many constraints in such details.
The future development of rest will also directly affect whether the design can have good vitality.

In general
Soap is superior in maturity
Rest.

Efficiency and ease of use:

The SOAP protocol defines message bodies and headers, And the scalability of message headers provides the basis for extension of various Internet standards,
WS-* series are relatively successful specifications. However, because
Due to various requirements, soap constantly expands its own protocol content, resulting in
Soap processing performance has declined. At the same time, it also increases in usability and learning costs.

Rest has been paid attention to by people. In fact, it is also very important because of its efficiency and simplicity and ease-of-use features. On the one hand, this efficiency stems from its resource-oriented interface design and operation abstraction, which simplifies developers' poor design and maximizes the use
The original design concept of HTTP application protocol. In my opinion
Rest also attracts developers by integrating the current
Many front-end technologies of Web2.0 improve development efficiency. For example
Rest-style
APIs have multiple return forms, except for the traditional
XML is used as the data bearer, and (
JSON, RSS, atom) and other forms, which can be good for many front-end website developers.
Mashup various resource information.

Therefore, in terms of efficiency and ease of use,
Better rest.

Security:

This can be put into maturity. However, in the current Internet application and platform development and design process, security has been raised to a very high level, especially as an external interface for third-party calls, security may be higher than the business logic itself.

Soap is used for security.
XML-Security and
XML-signature consists of two specifications
WS-Security has been supported by various vendors to implement security control,
. Net,
PHP,
Java is already well supported (although there are still incompatibility issues in some details, intercommunication is basically acceptable ).

Rest does not have any specifications to describe security, and is now open
REST style
API websites are divided into two types: custom security information is encapsulated in messages (in fact
There is no difference between soap). The other is hardware.
SSL
But this only ensures point-to-point security.
SSL is useless. Security is also a big problem this year.
At the BEA summit, we saw a demonstration.
Inter-website implemented by saml2
SSO is actually directly used
XML-Security and
XML-signature, the efficiency does not seem very high. Future
It is unknown whether the two standards will be used in the rest normalization and generalization processes, but the more they are added,
Rest loses its efficiency.

Application Design and Transformation:

Our system either has services that need to be released, or services that have just been designed, but the traditional design philosophy of developers enables
It takes some time for the rest form to be accepted. In terms of resource-based data service interface design
It is easier to design the rest concept. For some complex service interfaces
The rest style is somewhat far-fetched. In fact, you can see the interfaces of various major websites.
The function name is used as a parameter, which obviously violates
The design concept of rest itself.

While
Soap itself is oriented
Designed by RPC, developers are very easy to accept, so there is no adaptation process.

In general, it is still an old concept, and the best fit is the best

There is no good or bad technology, but it is not suitable. If a good technology or idea is misused, it will be reversed.
Rest and
Soap has its own advantages, and if it is transformed in some scenarios
Rest, in fact, will go
Soap (for example, security ).

Rest is suitable for Resource-based service interfaces and especially suitable for scenarios with high efficiency requirements but low security requirements. While
The maturity of soap can be provided to multiple development languages, facilitating interface design with high security requirements. Therefore, I think it makes no sense to say that the design model will be dominant. The key is to look at the application scenario.

At the same time, it is important not to distort it.
Rest is now under development for many websites
Rest-style interfaces are actually learning their own shapes, without knowing their own minds. They finally become nondescribable. performance is not good, and security is not guaranteed. It seems like a bag.