Many people ask us whether we should choose the most popular RestFul architecture or the old webService when designing the underlying service? Today, I will explain these two concepts, and choose which one is more reasonable under what circumstances.
First of all, you need to understand: REST is an architectural style, and its core is resource-oriented; while the underlying SOAP protocol of webService, the main core is activity-oriented;
Related concepts:
SOAP
What is SOAP, I think needless to say, google is full of eyes. In fact, SOAP was originally a solution for RPC. It is a simple object access protocol and is very lightweight. At the same time, as an application protocol, it can transmit messages based on multiple transmission protocols (Http, SMTP, etc.). However, with the wide application of SOAP as a WebService, additional content is continuously added, which makes SOAP very heavy for developers now and has a high threshold for use. In the subsequent development process of SOAP, the formulation of a series of protocols of WS-* increased the maturity of SOAP and also 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. Today, the Http protocol is widely used, more and more is used as a transmission protocol, rather than the original designer. Considered application protocol. The SOAP-type WebService is the best example. The SOAP message completely carries the Http protocol as a message, so that various parameters (such as encoding, error code, etc.) in the Http protocol are ignored. In fact, the most lightweight application protocol is the Http protocol. The get, post, put and delete abstracted by the Http protocol are like the most basic additions, deletions, changes and searches in the database, and various resources on the Internet are like the records in the database. The operation of various resources can always be abstracted into this. There are four basic operations. After defining the rules for locating resources, operations on resources can be implemented through the standard Http protocol, and developers will also benefit from this lightweight protocol.
REST is specially designed and developed for network applications to reduce the complexity of development and improve the scalability of the system. REST proposes design concepts and guidelines as:
1. Everything on the network can be abstracted as a resource
2. Each resource has a unique resource identifier, and operations on the resource will not change these identifiers
3. All operations are stateless
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, acquire, update, and delete to complete related operations and processing. We can identify and locate resources by the Universal Resource Identifier (URI), and the operations performed on these resources are defined by the HTTP specification. Its core operations are only GET, PUT, POST, DELETE. Since REST enforces that all operations must be stateless, there is no context constraint. If distributed, the cluster does not need to consider the context and session retention. Greatly improve the scalability of the system.
SOAP webService has strict specifications and standards, including security, transaction and other aspects. At the same time, SOAP emphasizes the separation of operation methods and operation objects. It is defined by WSDL file specification and XSD file respectively.
In this sense, whether or not to use REST needs to consider whether the abstraction and identification of the resource itself is difficult. If it is a simple business operation like adding, deleting, modifying and checking, it is easier to abstract resources, while for complex business activities abstract resources Not a simple matter. For example, user level verification, transfer, transaction processing, etc., these are often not easily abstracted into resources.
Secondly, if there are strict specifications and standard definition requirements, and the previous specification standards need to guide the integration and development of multiple business systems, the SOAP style has obvious advantages due to the clear specification and standard definition. We can strictly define the relevant interface methods and interface transfer data before starting and implementing. (In many cases, in order to be compatible with previous projects and the front-end calling logic code cannot be moved, changing the underlying application generally requires the use of webService mode development, because the old code already has clear method definitions and parameter types and numbers. etc. statement)
简单数据操作，无事务处理，开发和调用简单这些是使用REST架构风格的优势。而对于较为复杂的面向活动的服务，如果我们还是使用REST，很多时候都是仍然是传统的面向活动的思想通过转换工具再转换得到REST服务，这种使用方式是没有意义的。