Web Service Advanced (vii) on SOAP Webservice and restful webservice__web

A brief talk on Soap Webservice and restful Webservice

Rest is an architectural style whose core is resource-oriented, and rest is designed and developed specifically for network applications to reduce the complexity of development and improve the scalability of the system. Rest presents design concepts and guidelines for:

1. All things on the web can be abstracted as resources (Resource)

2. Each resource has a unique resource identifier (resource identifier), and the operations on the resource do not change these identities

3. All operations are state-free.

Rest simplifies development, and its architecture follows the CRUD principle, which tells us that only four behaviors are required for resources (including network resources): Create, get, update, and delete to complete the relevant operations and processing. You can identify and locate resources through a Uniform Resource identifier (Universal Resource Identifier,uri), and actions taken against those resources are defined through the HTTP specification. Its core operation is only get,put,post,delete.

Because rest enforces that all operations must be stateless, there is no context constraint and, if distributed, the cluster does not need to consider context and session retention issues. Greatly improve the scalability of the system.

For the choice of soap webservice and restful webservice, the first thing to understand is that soap is biased toward activity-oriented, with strict specifications and standards, including security, transactions, and so on, while soap emphasizes the separation of operation methods and manipulation objects, The WSDL file specification and XSD file are defined separately. While rest emphasizes resource-oriented, the rest architecture style can be used as long as the objects we want to manipulate can be abstracted as resources.

In this sense, it is easy to use rest to consider the abstraction and identification of the resource itself, and if it is simply a business operation that is similar to or modified, it is easier to abstract resources, and abstract resources for complex business activities is not a simple matter. For example, check user rating, transfer, transaction processing, etc., these are often not easy to simply abstract as resources.

Secondly, if there is a strict specification and standard definition requirements, and the pre-standard standards need to guide the integration and development of multiple business systems, SOAP style because of a clear definition of standard standards are obvious advantages. We can strictly define the relevant interface methods and interfaces before the start and implementation of the data transfer.

Simple data manipulation, no transaction processing, development and invocation simplicity are the advantages of using the rest architecture style. For more complex, activity-oriented services, if we still use rest, many times it is still the traditional idea of activity-oriented thinking through the conversion tool to convert to rest services, this way of use is meaningless.

Rest core is URL and resource oriented, URL replaces the original complex operation method. Rest allows us to design systems through URLs, just as test-driven development uses test case design class interfaces. All things that can be abstracted as resources can use the restful URL, and as we can see in a traditional soap-based query order service, the service first has the input query criteria and then the output result set. So for a similar scenario to use rest, it is inevitable to split the traditional SOAP service into an HTTP POST operation and an HTTP GET operation. The front is input, and the following is the output.

The key to using rest is how to abstract resources, the more accurate the abstraction, the better the application of rest. How to abstract, resource-oriented design and traditional structure-and object-oriented design differences, resources and objects, database tables is another problem in the analysis of design time to consider. How to change the traditional soap analysis design idea in rest analysis design is an important problem.

WebService occupies a very important place in the fundamental technology implementation of SOA, and often we mention WebService's first idea is that SOAP messages interact on a variety of transport protocols. The idea of rest in recent years has been followed by a gradual acceptance of SOA, and the constant opening of APIs to developers in major websites has sparked a webservice of restful style. SOAP

What is soap, I don't want to say more, Google is an eyeful. 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 pass messages (HTTP,SMTP, etc.). But as soap is widely used as a webservice, additional content is constantly being added, making it a very high threshold for developers to think of soap as heavy. In the development of soap, the ws-* of a series of protocols increased the maturity of soap and added a burden to soap. REST

Rest is not a protocol nor 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 designers consider the application protocol. The webservice of the soap type is the best example of a SOAP message that simply hosts the HTTP protocol as a message, ignoring the various parameters in the HTTP protocol, such as encoding, error code, and so on. In fact, the most lightweight application protocol is the HTTP protocol. The HTTP protocol abstract Get,post,put,delete is like the database the most basic additions and deletions to check, and the Internet resources are like records in the database (perhaps this analogy is not very good), for the operation of various resources can always abstract into these four basic operations, After defining the rules for locating resources, the operation of resources can be achieved through a standard HTTP protocol, and developers will benefit from this lightweight protocol. Rest thought

Due to the following have several key points: 1. Resource-oriented interface design

All interface design is designed for the resources, it is similar to our object-oriented and process-oriented design differences, but now the network of operational entities are regarded as resources, while the design of the URI also embodies the location of the design of resources. Some of the Web site's API design is said to be rest design, in fact, is a mixture of rpc-rest, not rest of the mind. 2. CRUD based on abstract operations

This is very simple, get,put,post,delete in HTTP corresponds to the Read,update,create,delete four kinds of operations, if only as the operation of resources, the abstraction becomes these four is enough, But for some of today's complex business service interface designs, this abstraction may not be enough.       In fact, this is also a few of the following Web site API design exposes such a problem, if you want to completely follow the rest of the idea of design, then the applicable environment will be limited, but not to put the Sihai. 3. HTTP is an application protocol rather than a transport protocol

This is evident in the API analysis of the following major websites, in fact, some sites have come to the old soap road, said that the rest of the concept of design, is actually made a set of private soap protocol, so called the rest-style custom SOAP protocol. 4. No state, self contained

This is not just for rest, as interface design needs to be able to do this, but also as the most basic guarantee of scalability and efficiency, even with the webservice of soap. Comparison of SOAP WebService and restful WebService Maturity Level

In general, soap is superior to rest in terms of maturity.

Although soap has evolved from its original intention, it has reached a more mature situation for the distribution and invocation of heterogeneous environmental services, as well as vendor support. Different platforms, Web service that interacts with soap between development languages can be better exchanged (in some complex and special parameters and return object parsing, the protocol is not detailed, resulting in the need for partial correction).

Rest of the big Web sites have released their own development APIs, many of which provide soap and rest two web Service, according to the survey of the rest of the site's usage is higher than soap. But since rest is just an idea of implementing resource operations based on HTTP protocols, the rest implementations of each Web site have a set of different styles for the rest API of each major web site. It is also because of this individual implementation that the performance and availability are much higher than the soap-published Web service, but the unification aspect is far less than soap. Because the SP of these big website often concentrates on this website API development, therefore the versatility request is not high.

Because there is no authoritative protocol similar to SOAP as a specification, the various protocols for rest implementation can only be private, and of course need to follow rest, but there are too many areas of detail where there is no constraint. Rest of the future development trend of the norms will also directly affect the design of this part can have a very good vitality. efficiency and ease of use

Rest is more than a chip.

The SOAP protocol is defined for both the message body and the message headers, while the scalability of the message headers provides an extended basis for various Internet standards, and the Ws-* series is a more successful specification. But also because SOAP expands the content of its own protocol as a result of various requirements, the performance in SOAP processing has decreased. At the same time, the ease of use and the cost of learning also increased.

Rest is valued by people, but it is also because of its efficiency and simplicity and ease of use. This efficiency stems from its resource-oriented interface design and Operation Abstraction simplifies the developer's bad design, but also maximizes the use of HTTP Initial application protocol design concept. At the same time, it seems to me that rest has a very attractive developer who is able to integrate many of the front-end technologies of the current Web2.0 to improve development efficiency. For example, many large Web sites open to the rest-style API will have a variety of return forms, in addition to traditional XML as data bearer, as well as (Json,rss,atom) and other forms, this is a lot of web 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 mentioned a high level, especially as an external interface to the third party calls, security may be higher than the business logic itself.

The security aspect of SOAP is security control by using the xml-security and xml-signature two specifications, which are now supported by various vendors, and are currently backed by the vendor. NET, PHP, Java has been well supported (although there are some incompatibilities in the details, interoperability is basically possible). "

Rest does not have any specifications for security. At the same time, the Web site of the open rest-style API is now divided into two main types, one that customizes security information in the message (which, in fact, is no different from soap), and which is secured by hardware SSL, but that only guarantees point-to-point security, If you need more than a little bit of transmission, SSL can do nothing. Security This is also a big problem, at the BEA summit to see a demonstration using SAML2 implementation of the website SSO, in fact, is directly using the xml-security and xml-signature, efficiency does not look very high. Whether security in future rest normalization and generalization will also take these two specifications is unknown, but the more you join, the more the rest loses its efficiency advantage. application design and Transformation

Our systems either already have services that need to be posted, or services that have just been designed, but the traditional design idea of the developer takes a little time to get the rest form accepted. At the same time, it is relatively easy to design on the basis of the rest in the design of the Resource Data service interface, and for some complex service interfaces, it may be far-fetched to design in the rest style. This can actually take a look at the interface of the major web site can know, many sites will also pass the name of function as a parameter, this obviously has violated the rest itself design ideas. and soap itself is designed for RPC, developers are very easy to accept, so there is no process of adaptation. In general, it is still an old concept, the best for the

The technology is not good or bad, only is not suitable, a kind of fine technology and thought is misused, then will get the counter effect. Rest and soap each have their own advantages, and if you change the rest in some scenarios, you actually move to soap (for example, security).

Rest is appropriate for resource-oriented service interfaces, and is particularly suited for scenarios where efficiency requirements are high, but security requirements are not high. And the maturity of soap can give the need to provide for the development of languages, for the security requirements of the interface design more convenient. So I think it doesn't make sense to say exactly 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 rest, many sites are now follow the development of rest-style interface, in fact, are learning its shape, do not know its heart, finally made nondescript, performance does not go, security and guarantee, there is a seemingly presentable skin. Beautiful picture of the United States