What is a REST ful Web service?
Rest is an architectural style whose core is resource-oriented, and rest 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.
Rest ful the use of rest in the application of the problem is to consider whether the abstraction and identification of the resource itself is difficult, if itself is simple like adding and deleting the business operations, then the abstraction of resources is relatively easy, and for complex business activities abstract resources is not a simple thing. such as verifying user levels, transfers, transactions, etc., are often not easy to abstract as resources.
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.
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,atom) and other forms, which for many site front-end developers can be a good mashup of various resource information
The security 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 nondescript, performance on the not, security and guarantee not.
The maturity of soap, although developed to now out of the original intention, but for the heterogeneous Environment Service Release and invocation, and vendor support has reached a more mature situation. Different platforms, the development of the language between the use of soap to interact with the Web service can be better interoperability.
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.
Web Service comparison with RESTful Web service
