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

talking about soap Webservice and restful Webservice

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

1. Everything on the network can be abstracted as a resource (Resource)

2. Each resource has a unique resource identifier (resource identifier), and the operation of the resource does not change these identities

3. All operations are non-stateful

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, Fetch, update, and delete to complete related operations and processes. You can identify and locate resources through a Uniform Resource identifier (Universal Resource Identifier,uri), and the actions that are performed on those resources are defined through the HTTP specification. Its core operation is only get,put,post,delete.

Since rest enforces that all operations must be stateless, there is no context constraint, and if distributed, the cluster does not need to consider the problem of context and session retention. 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 towards activity-oriented, with strict specifications and standards, including security, transactions, and so on, while soap emphasizes the separation of operations and operations objects, The WSDL file specification and the XSD file are defined separately. While rest emphasizes resource-oriented, we can use the rest architecture style as long as the objects we want to manipulate can be abstracted as resources.

If you use rest in this sense, it is difficult to consider the abstraction and identification of the resource itself, and if it is simply a business operation that is similar to adding and removing changes, then abstract resources are easier, and abstract resources for complex business activities are not a simple matter. such as verifying user levels, transfers, transaction processing, and so on, are often not easy to abstract as a resource.

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

Simple data manipulation, no transaction processing, development and invocation simplicity these are the advantages of using the rest architecture style. In the case of more complex activity-oriented services, if we still use rest, it is very often that the traditional activity-oriented ideas are converted to rest services through conversion tools, which is meaningless.

The rest core is URL and resource-oriented, and the URL replaces the original complex operation method. Rest allows us to design the system through a URL, just as test-driven development uses a test case design class interface. All things that can be abstracted into resources can use restful URLs, as we can see in the traditional SOAP implementation of a query order service, this service first has the input query condition, then the output result set. So for a similar scenario to use rest, it is inevitable that the traditional soap service will be split into an HTTP POST operation and an HTTP GET operation. The front is the input, and the back is the 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 and traditional architecture-oriented and object-based design differences, resources and objects, database table differences are another issue to be considered in the analysis of design. How to change the traditional soap analysis design idea in rest analysis design is an important problem.

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.

Rest thought

Here are a few 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 rather than 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. No status, 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 the use of soap webservice.

Comparison of SOAP WebService and restful WebService Maturity Level

In general, soap is superior to 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).

Many of the rest of the world's largest Web sites have published their own APIs, many of which provide soap and rest two web Service, according to the rest style of the survey part of the site 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. The future development of rest will have a direct impact on whether this part of the design can have a good vitality.

efficiency and ease of use

Rest is a better one.

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 also a big problem, in the BEA summit to see the demonstration using SAML2 to achieve the SSO, in fact, the direct use of xml-security and xml-signature, efficiency does not look very high. It is not known whether security in future rest normalization and generalization will take 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 reluctant 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 change rest in some scenarios, you will actually go 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 is very important is not to distort the rest, now many Web sites are the follow-up to develop the rest-style interface, in fact, are learning its shape, do not know its heart, finally made nondescript, performance on not, security and can not guarantee, the Apostle has a seemingly smarty pants of the skin.

American and American pictures

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