REST & SOAP WebService Summary

REST:

Rest is an architectural design, characterized by resource-oriented, where anything that exists on the Internet can be understood as a resource, and rest compared to soap ws has a relatively low development threshold.

1. Things on the network are abstracted into resources, each resource corresponding to a unique resource identifier (URI)

2. All operations on the resource are stateless

Rest follows the HTTP specification, which corresponds to the HTTP method-get/post/put/delete (fetch, increment, modify, delete) of the core operation of the resource, and obtains and operates the resource through the URI.

Soap:

SOAP has strict specifications and standards, the management of security and things more mature, colleagues emphasize the operation method and object separation, there are WSDL and XSD specification definition. For complex business activity logic,

It is not simple to abstract the things that will be manipulated into resources, such as transaction processing, SOAP is a better choice.

Comparison of SOAP WebService and RESTful WebService (RPM)

Maturity (overall soap is better than rest in terms of maturity)

Although soap is now out of the original intention, the release and invocation of heterogeneous environment services, as well as vendor support, have reached a mature situation. Different platforms, the development of the language through soap to interact with the Web service can be good interoperability (in some complex and special parameters and return object parsing, the protocol is not very detailed provisions, resulting in the need for partial correction)

Rest many of the big Web sites have published their own development API, many of which provide soap and rest two web Service, according to the survey part of the site's rest style usage is higher than soap. But since rest is just an idea for resource manipulation based on the HTTP protocol, the rest implementations of each Web site have their own set of the rest API styles for each major website. It is also because of this individual implementation that the performance and usability are much higher than the soap-published Web service, but the unified common aspect is far less than soap. Because the SP of these large websites tend to focus on the API development of this website, the generality requirement is not high.

Since there is no authoritative protocol similar to SOAP as a specification, the various protocols that rest implements are only private, and of course need to follow the rest idea, but there are too many areas of detail that are unconstrained. Rest of the future development of the norm will also directly affect the design of this part can have a good vitality.

efficiency and ease of use (rest wins)

The SOAP protocol defines both the message body and the message header, while the extensibility of the message header provides an extended basis for various Internet standards, and the WS-* series is the more successful specification. However, the performance of soap processing has declined due to the fact that soap constantly expands its own protocol content due to various requirements. There has also been an increase in ease of use and learning costs.

Rest is a big part of people's attention, but also because of its high efficiency and simple and easy-to-use features. This efficiency stems from its resource-oriented interface design and operational abstraction, which simplifies the developer's poor design and maximizes the use of HTTP's initial application protocol design philosophy. At the same time, it seems to me that rest has a very attractive developer is the ability to integrate the current Web2.0 of many front-end technology to improve development efficiency. For example, many large Web sites open the rest-style API will have a variety of return forms, in addition to traditional XML as a data bearer, as well as (Json,rss,atom) and other forms, which for many site front-end developers can be a good mashup of various resource information.

Security:

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

Soap is security controlled by the use of xml-security and xml-signature two specifications ws-security to achieve security control, currently has been supported by various manufacturers,. NET, PHP, Java have already had a good support for it (although there are some incompatibilities in some details, interoperability is basically possible).

Rest does not have any specifications for the security aspects, while the open Rest-style API Web site is mainly divided into two, one is to customize the security information encapsulated in the message (in fact, there is no difference between soap), and the other is to rely on hardware SSL to protect, but this can only guarantee the point-to security, If there is a need for multi-point transmission, SSL can do nothing. Security this is actually a big problem, this year at the BEA summit to see the demonstration using SAML2 implementation of the inter-site SSO, in fact, the direct use of xml-security and xml-signature, efficiency does not look very high. It is unknown whether security in future rest normalization and generalization will be used in both of these specifications, but the more you join, the more benefits rest loses in its efficiency.

REST & SOAP WebService Summary