SOAP Webservice and RESTful Webservice, webservicerestful

SOAP Webservice and RESTful Webservice, webservicerestful
REST is an architectural style. Its core is resource-oriented. REST is designed and developed specifically for network applications to reduce development complexity and improve system scalability. REST proposes the following design concepts and principles:
1. Everything on the network can be abstracted as a resource)
2. Each resource has a unique resource identifier. operations on the resource do not change these identifiers.
3. All operations are stateless.

The simplified REST development follows the CRUD principle. This principle tells us that only four actions are required for resources (including network resources): Creation and acquisition, update and delete to complete related operations and processing. You can identify and locate resources by using the Universal Resource Identifier (URI) and perform operations on these resources according to HTTP specifications. Its core operations include GET, PUT, POST, and DELETE.

Since REST forces all operations to be stateless, there is no context constraint. For distributed operations, the cluster does not need to consider context and session persistence. Greatly improve the scalability of the system.

For the choice of SOAP Webservice and Restful Webservice, we must first understand that SOAP tends to be activity-oriented and has strict specifications and standards, including security, transactions, and other aspects, at the same time, SOAP emphasizes the separation of operation methods and operation objects, which are defined by the WSDL file specification and the XSD file respectively. While REST emphasizes resource-oriented, the REST architecture style can be used as long as the objects to be operated can be abstracted as resources.

In this sense, it is necessary to consider whether to use REST to abstract and identify resources. If it is a simple business operation similar to adding, deleting, modifying, and querying resources, abstract resources are easier, but abstract resources for complex business activities are not a simple task. For example, user level verification, transfer, and transaction processing are not easily abstracted as resources.

Second, if there are strict standards and standards definition requirements, and the preliminary standards need to guide the integration and development of multiple business systems, the SOAP style has obvious advantages due to its clear standard definition. We can strictly define relevant interface methods and interfaces for data transmission before we start and implement them.

Simple data operations, no transaction processing, simple development and calling are advantages of the REST architecture. For more complex activity-oriented services, if we still use REST, it is often the traditional activity-oriented idea that is converted into REST services through conversion tools, this method is meaningless.

As mentioned in another article, the core of REST is url and resource-oriented, and url replaces the original complex operation methods. REST allows us to design a system through a url, just as test-driven development uses the test case design class interface. All the things that can be abstracted as resources can use RESTful URLs. When we use a traditional SOAP method to query order services, we can see that, this service first has the input query conditions, and then the output result set. If you want to use REST in similar scenarios, the traditional SOAP service will inevitably be split into an http post operation and an http get operation. Input is followed by output.

The key to using REST is how to abstract resources. The more accurate the abstraction, the better the REST application. How to abstract, resource-oriented design is different from traditional structure-oriented and object-oriented design. The difference between resources, objects, and database tables is another issue to be considered during analysis and design. How to change the traditional SOAP analysis design concept in REST analysis design is also an important issue.

Reproduced below from: http://hi.baidu.com/gaohong230/blog/item/cd3924396bc7332fb9998f52.html

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 databases (which may not be a good analogy). Operations on various resources can always be abstracted into these four basic operations, after defining the resource locating rules, resource operations can be implemented through the standard Http protocol, 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 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.

Comparison between SOAP Webservice and RESTful Webservice

Maturity (in general, SOAP is superior to REST in 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.

Efficiency and ease of use (better REST)

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.

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.