Comparison of REST WebService with soap WebService

WebService occupies an important position in the basic technology implementation of SOA, and often we mention that the first idea of WebService is that SOAP messages interact on various transport protocols. In recent years, the idea of rest has been embraced by the SOA, while the large Web sites are constantly opening APIs to developers, and the rest-style webservice craze has been aroused.

Soap

What is soap, I want to say no more, Google an eyeful is. In fact, soap is the first solution for RPC, Simple Object Access protocol, very lightweight, and as an application protocol can be based on a variety of transport protocols to deliver messages (HTTP,SMTP, etc.). But with the extensive use of soap as a webservice, the added content continues to grow, making the developers feel that soap is heavy and the threshold is high. In the subsequent development of soap, the formulation of a series of WS-* protocols increases the maturity of soap and adds a burden to soap.

REST

Rest is not really a protocol or a standard, but the design of the HTTP protocol is interpreted, in the HTTP protocol is widely used today, more and more as a transport protocol, rather than the original designer to consider the application protocol. The webservice of SOAP type is the best example, the SOAP message is simply the HTTP protocol as a message bearer, so that the HTTP protocol in the various parameters (such as encoding, error code, etc.) are disregard. In fact, the most lightweight application protocol is the HTTP protocol. HTTP protocol abstract Get,post,put,delete is like the database of the most basic additions and deletions, and the internet is like a variety of resources on the database record (perhaps this analogy is not very good), for the operation of various resources can always be abstracted into these four basic operations, After defining the rules for locating resources, the operation of the resources can be implemented through standard HTTP protocols, and developers will benefit from this lightweight protocol.

The rest idea boils down to the following key points:

1. Resource-oriented interface design

All interface design is designed for the resources, it is very similar to our object-oriented and process-oriented design differences, but now the network of operating entities as resources to look at, while the design of the URI also embodies the design of the resource positioning. Some of the Web site's API designs are said to be rest design, which is actually a rpc-rest, not a rest idea.

2. Abstract operations-based CRUD

This is very simple, HTTP get,put,post,delete corresponding to the Read,update,create,delete four operations, if only as a resource for the operation, the abstraction of these four are enough, But for some of today's complex business service interface designs, this abstraction may not be sufficient. In fact, this is also in the back of several Web site API design exposes such a problem, if you want to completely follow the rest of the idea to design, then the applicable environment will be limited, and not put in a universal standard .

3.Http is an application protocol, not a transport protocol

This is in the back of the major Web site API analysis is very obvious, in fact, some sites have come to the old way of soap, said is the concept of rest design, in fact, is a set of private soap protocol, so called the rest-style custom SOAP protocol.

4. Stateless, self-contained this is not only for rest, as an interface design needs to be able to do this, but also as an extensible and

The most basic guarantee of efficiency, even with the webservice of soap. REST vs SOAP

Maturity Level:

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.

In general, soap is superior to rest in terms of maturity. Efficiency and ease of use:

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,a TOM) and other forms, which for many site front-end developers can be a good mashup of various resource information.

Therefore, rest is better in terms of efficiency and ease of use. 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 in the security aspect by using xml-security and xml-signature Two specifications constitute the ws-security to achieve security control, currently has been supported by various manufacturers,. NET, PHP, Java has been very good support ( 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.

Application Design and Retrofit:

Our system either already has the services that need to be published or is just designed, but the traditional design ideas of the developers will take a little time to accept the form of rest. At the same time in the resource-based data service interface design in accordance with the rest of the idea of design is relatively easy, and for some complex service interface, may be strong to follow the rest of the style of design will be a bit far-fetched. This point can actually look at the interface of the major sites can be known, many sites also have to pass in the name of function as parameters, which clearly has violated the rest of the design ideas.

and soap itself is designed for RPC, developers are very easy to accept, so there is no adaptation of the process.

In general, is still an old concept, suitable is the best

The technology is not good or bad, only if it is appropriate, a great technology and ideas have been misused, then it will be counterproductive. Rest and soap each have their own merits, and if you are going to transform rest in some scenarios, you will actually move to soap (for example, security).

Rest is appropriate for resource-based service interfaces, and is particularly well suited for scenarios where the requirements for efficiency are high, but not for the security requirements. However, the maturity of soap can be provided to many developing languages, which facilitates the design of interfaces with high security requirements. So I think it's pointless to just say what design patterns will dominate, and the key is to look at the application scenario.

At the same time it is important to not distort the rest now many Web sites are the follow-up to develop a rest-style interface, in fact, are learning its shape, do not know its heart, finally made no fish and fish, performance, security and can not guarantee, the apostles have a look like a sample of the skin.

Comparison of REST WebService with soap WebService