Comparison between REST WebService and SOAP WebService, webservicesoap

Comparison between REST WebService and SOAP WebService, webservicesoap

 Comparison between REST WebService and SOAP WebService

In the basic technical implementation of SOA, WebService occupies a very important position. We usually mention the first idea of WebService is that SOAP messages interact on various transmission protocols. In recent years, the idea of REST has gradually been accepted by everyone along with SOA. At the same time, the open APIs provided to developers by major websites have aroused the upsurge of REST-style WebService.

SOAP:

What is SOAP? I don't want to mention it. google is full of eyes. In fact, SOAP was originally a solution for RPC. Simple Object Access Protocol is very lightweight. At the same time, it can be used as an application protocol to transmit messages (Http, SMTP, etc.) based on multiple transmission protocols ). However, with the wide application of SOAP as a WebService and the increasing addition of content, developers now think that SOAP is very heavy and has a high threshold for use. In the subsequent development of SOAP, the establishment of a series of WS-* protocols increased the maturity of SOAP and increased the burden on SOAP.

 

REST:

In fact, REST is not a protocol or a standard, but an interpretation of the original design of the Http protocol. Nowadays, Http is widely used as a transmission protocol, rather than the application protocol that the original designer considered. A soap-type WebService is the best example. a soap message simply carries an Http protocol as a message, so that all parameters (such as encoding and error codes) in the Http protocol are ignored. In fact, the most lightweight application protocol is the Http protocol. The abstract get, post, put, and delete in the Http protocol is like the most basic addition, deletion, modification, and query in the database. The 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, resource operations can be implemented through the standard Http protocol, 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 designs. However, the operating entities on the network are regarded as resources, at the same time, the URI design also reflects the resource positioning design. There will be some web site API design said that REST design, in fact, is a mixture of RPC-REST, not the idea of REST.

 

2. CRUD based on abstract operations

 

This is very simple. The get, put, post, and delete operations in Http correspond to four types of operations: read, update, create, and delete. If they are only operations on resources, it is enough to abstract these four types. However, for some complex business service interface designs, such abstraction may not be able to meet the requirements. In fact, this problem is also exposed in the API design of the following websites. If you want to design completely according to the REST idea, then the applicable environment will be limited, it is not universally applicable.

 

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

 

This is clearly reflected in the API analysis of major websites. In fact, some websites are already on the way to SOAP, which is the concept design of REST, it is actually a set of private SOAP protocols, so it is called a REST-style custom SOAP protocol.

 

4. Stateless, self-contained

This is not only for REST, but also for interface design. It is also the most basic guarantee for scalability and efficiency, even for WebService using SOAP.

 

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. Web services that interact with each other through SOAP on different platforms can communicate well (in some complex and special parameters and response object parsing, the Protocol is not detailed, as a result, some corrections are required)

 

REST many foreign websites have released their own development APIs, many of which provide SOAP and REST Web Services. According to the survey, the rest style usage of some websites is higher than that of SOAP. However, since REST is just an idea of implementing Resource Operations Based on Http protocol, there is a set of REST implementations for each website. The rest api style of each major website will be discussed later. It is precisely because of their respective implementations that the performance and availability will be much higher than the web service released by SOAP, but the unified and universal aspect is far inferior to SOAP. Because the SP of these large websites often focus on the API development of this website, the general requirements are not high.

 

Since there is no authoritative protocol similar to SOAP as a specification, various REST-implemented protocols can only be regarded as private protocols. Of course, they must follow 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 better than REST in terms of maturity.

 

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. The WS-* series are relatively successful specifications. However, due to the constant expansion of the content of SOAP Protocol due to various requirements, the performance of SOAP processing 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. This efficiency stems from its resource-oriented interface design and operation abstraction, which simplifies developers' poor design and maximizes the use of Http's original application protocol design philosophy. At the same time, in my opinion, another attractive developer in REST is that it can well integrate many front-end technologies of current Web2.0 to improve development efficiency. For example, many REST APIs open to large websites have multiple return forms, except for the traditional xml as data bearer and JSON, RSS, ATOM, and other forms, this is a good way for many front-end website developers to prepare various resource information for mashups.

 

Therefore, REST is superior in terms of efficiency and ease of use.

 

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.

 

In terms of Security, SOAP uses XML-Security and XML-Signature to form WS-Security to implement Security control. Currently, it has been supported by various vendors ,. net, php, and java are already well supported (although some details are still incompatible, it is basically possible to connect ).

 

REST does not have any specifications to describe security. At the same time, websites that open REST APIs are mainly divided into two types, one is custom security information encapsulated in messages (which is no different from SOAP), and the other is guaranteed by hardware SSL, however, this only ensures point-to-point security. SSL is powerless if multi-point transmission is required. Security is also a big problem. At the BEA summit this year, we saw a demonstration of the use of SAML2 for inter-site SSO. In fact, XML-Security and XML-Signature were directly used, efficiency does not seem very high. In the future, it is unknown whether the two standards will be used in the REST normalization and generalization processes. However, the more you add, the more advantages that REST will lose its efficiency.

 

Application Design and Transformation:

 

Our system either has services that need to be released, or services that have just been designed, however, it takes a little time for developers to accept the REST form with their traditional design ideas. At the same time, it is easier to design resource-based data service interfaces according to the REST concept. For some complex service interfaces, it may be far-fetched to design according to the REST style. In fact, you can see the interfaces of various websites. Many websites also need to input the function name as the parameter, which obviously violates the REST design idea.

 

SOAP is designed for RPC, which is very easy for developers to accept. Therefore, 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. Both REST and SOAP have their own advantages. At the same time, if you transform REST in some scenarios, it will actually go to SOAP (such as security ).

 

REST is suitable for Resource-based service interfaces and especially suitable for scenarios with high efficiency requirements but low security requirements. 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 very important not to distort the REST. Many websites are now following the trend in developing restful interfaces. They are actually learning the REST interface. I don't know what it is, and the performance is not good, security is not guaranteed, and there is a seemingly similar leather bag.