REST and SOAP: Who is better or better?

Today, there are quite a few options for Web developers, from simplified database access technology to easy-to-use middleware service packaging technology and a variety of interesting client software. All these products and tools are designed to help Web developers develop the best Web applications at the fastest speed.

However, having a large number of optional software solutions and selecting specific solutions for specific parts of Web applications are challenging, currently, Web developers must keep track of various constantly changing standards and methods.

For example, the Web Service technology includes SOAPSimpleObjectAccessProtocol, Simple Object Access Protocol) and RESTRepresentationalStateTransfer, indicating state transfer. They are all effective solutions, but in specific scenarios, which solution is better depends on Web developers.

At present, most Web developers seem to understand REST, a solution that uses standard Uris for calling. REST is easy to understand, and it is supported by clients/servers that support HTTP/HTTPS. You can use the HTTPGET method to execute commands. Therefore, developers feel the advantages of REST: simple development, relying only on existing Web infrastructure, and low learning costs.

However, SOAP, as an old Web Service technology, will not leave the stage of history in the short term. In addition, with the emergence of SOAP1.2, some shortcomings in the SOAP impression have been improved, and the collection rate and ease of use have also been improved. Note that, starting from W3CSOAP1.2, SOAP does not represent SimpleObjectAccessProtocol Simple Object Access Protocol.

Compared with REST, SOAP1.2 has more overhead, but these overhead also bring some benefits. First, SOAP cannot be separated from XMLExtensibleMarkupLanguage in three aspects. It can be used as an extensible Markup Language): SOAP envelope is based on XML, which defines what is in a message and how to process it; A set of data-type encoding rules and planning of process calls and responses. The SOAP envelope is issued by the transmission protocol HTTP/HTTPS), RPCRemoteProcedureCall, remote process call) is executed, and an XML document is returned with the SOAP envelope.

It should be noted that the "common" transmission protocol is an advantage of SOAP. Currently, REST is based on HTTP/HTTPS, while SOAP supports any transmission protocol, from HTTP/HTTPS to SMTPSimpleMailTransferProtocol, Simple Mail Transfer Protocol), and even JMSJavaMessagingService, Java Message Passing service ). However, XML becomes a disadvantage because it is lengthy and time-consuming to parse.

However, the good news for Web developers is that the above two solutions are effective. Both REST and SOAP can solve many Web problems and challenges. In many cases, they can satisfy developers' requirements, that is, they can be used interchangeably.

But many people do not know that these two technologies can be used together. REST is easy to understand and get started with. However, due to its lack of standards, it is only considered as an architectural method. In comparison, SOAP is an industrial standard with well-defined protocols and a set of well-established rules, which are adopted in both large and small systems.

Therefore,Applicable scenarios of REST include:

Limited Bandwidth and resources do not forget that the returned structure can be defined by the developer.) any format. In addition, REST can be supported by any browser because it uses standard GET, PUT, POST, and DELETE verbs. In addition, REST can also use XMLHttpRequest objects currently supported by most browsers, which adds a lot of color to AJAX.

Completely stateless operations are not the best choice for operations that require multi-step execution. It is more appropriate to use SOAP. However, if you need stateless CRUDCreate/Read/Update/Delete, create/Read/Update/Delete) operations, you should use REST.

Cache considerations if you want to use the stateless operation feature to make information available for caching, REST is a good choice.

The above already covers many solutions. Why do we need to consider SOAP? As mentioned above, SOAP is well-defined and has complete specifications. REST is just a method that does not make any conventions for development. Therefore, if you encounter the following scenarios, SOAP is the best choice:

Asynchronous processing and calling if your application needs to ensure reliability and security, use SOAP. SOAP1.2 supplemented and defined standards such as WSRMWS-ReliableMessaging to ensure such operations.

If the provider/consumer sides must agree on the exchange format, it is more appropriate to use SOAP. SOAP1.2 provides strict standards for such interactions.

Stateful operations if the application requires context information and dialog State management, SOAP should be used. SOAP1.2 supplemented and defined standards such as WS-Security, WS-Transactions, and WS-Coordination. In contrast, the REST method requires developers to implement these framework work on their own.

As you can see, REST and SOAP have their own application. They have their own potential problems in terms of security and transport layer, but they can all complete the task, and in many cases they enrich the Web technical means. Therefore, in this topic, the best principle is the Flexibility principle, because at least in today's Web development, no matter what the problem is, web developers always have a way to use one of these two technologies.

Edit recommendations]