REST vs SOAP. Part 1. Feel the difference
Some time ago I googled the Internet about “REST vs SOAP”, read a couple of articles and seemed to understand everything, but did not feel any satisfaction from it. Something was wrong, either I didn’t feel the main idea, or I just read while listening to the new Mouzon and thinking about a new feature in the project. As time appeared, I decided to fill this gap by writing a useful article on this subject.
REST vs SOAP. Part 1. Feel the difference.
REST vs SOAP. Part 2. How is it easier and more efficient to organize platform communication?
A couple of months ago, in a cursory study of the issue, I realized about REST about the following:
With such recollections, I began surfing the Internet. The first thought was, why was the name REST chosen? Representational State Transfer, in Wikipedia translation “transferring the state of a presentation” ... No picture appears in my head even during the fourth reading. Herethey try to answer my question and even give how Roy Fielding (the person who formulated the principles of REST) himself explained the origin of the name. The idea boils down to the fact that a request for a resource from the server puts the client application in a certain state (state), and a request for the next resource changes the state of the application (transfer). And “Representational” means that the resource is returned not just like that, but in some kind of representation, for example, in a representation for a machine or in a representation for a person. It’s difficult, as for me, and it’s confusing, because state is just what is missing in the client-server relationship in the REST architecture. I would call something like "Standardized Data Operations", just first you need to come up with something, and then choose a bright name. And Fielding, in his dissertation, admits that the name was not invented to make it clear what it was about, but "is intended to evoke an image of how a well-designed Web application behaves." But this is nothing, let’s not be offended by a respected person, we also often formulated everything in theses so that it was as incomprehensible as possible and it was impossible to find fault. There was also a good formulation of the idea in Russian - “presentation of data in a format convenient for the client” . In fairness, it should be noted that while I formulated my arguments about the inconsistency of the name, I saw in it some logic, at least in the English version.
It is important to understand thatREST is not a protocol or standard, but an architectural style . This style has its own principles. Let me copy them from the source I like and comment:
The term RESTful (web) service just used just means a service implemented using REST principles. So what gives us following these same REST principles? For starters, I would call simplicity the main advantage of the REST architecture. The simplicity of the idea, the simplicity of developing and adding functionality to RESTful applications. The idea is so simple and universal that it is even difficult to grasp at first. We do not add any new layer to our already multi-layer programmer cake, but simply use the long-recognized standards. Therefore, in order to answer the question about the advantages and disadvantages and to make the analysis more meaningful, I propose moving on to comparing the SOAP and REST approaches.
Let me give you a couple of examples to understand the difference between the approaches. The bookmaker ordered a service for working with football statistics. Custom functionality - get a list of matches, get details about a match. For editors - edit (Create, Edit, Delete) the list of matches, edit the details of the match. For such a task, you definitely need to choose the REST approach and get benefits from its simplicity and naturalness in interaction with HTTP. Here we do not need SOAP envelopes, SOAP main post offices and SOAP airmail, which can use any brand of aircraft. We just need to implement the following:
Everything is very simple! Now the example is more complicated. The same bookmaker wanted an API for betting on live matches. This procedure includes numerous checks, for example, whether the bid continues to be relevant, if the coefficient has not changed, or if the maximum bid amount for the market has been exceeded. After this, a money transaction occurs, the results of which are recorded in the primary and backup databases. Only after that the client receives an answer about the success of the operation. It clearly observes the focus on operations, there are increased requirements for security and stability of the application, so it is advisable to use SOAP.
And a couple of tasks in order to feel the topic:
What approaches would you use in these tasks?
I also wanted to write about the fact that all this gives the .NET developer and how to use it for my own purposes, but I see that the article’s tediousness index is approaching critical, so I’ll round out. In order to lower the same indicator, I deliberately avoided security aspects and, for example, answering the question “How is authentication possible in the REST architecture, if the reader throughout this article was told that the RESTful service should be stateless?”
And the conclusions of the article will be as follows:
Table of Contents:
REST vs SOAP. Part 1. Feel the difference.
REST vs SOAP. Part 2. How is it easier and more efficient to organize platform communication?
A couple of months ago, in a cursory study of the issue, I realized about REST about the following:
- Everything is a resource with a unique identifier (URL)
- All client operations with the stateless server, i.e. the server should not store any client information at all - no session
- All requests can be divided into 4 types in accordance with CRUD , and each type is mapped to the HTTP method - Post, Get, Put and Delete
- All logic revolves around resources, not operations
With such recollections, I began surfing the Internet. The first thought was, why was the name REST chosen? Representational State Transfer, in Wikipedia translation “transferring the state of a presentation” ... No picture appears in my head even during the fourth reading. Herethey try to answer my question and even give how Roy Fielding (the person who formulated the principles of REST) himself explained the origin of the name. The idea boils down to the fact that a request for a resource from the server puts the client application in a certain state (state), and a request for the next resource changes the state of the application (transfer). And “Representational” means that the resource is returned not just like that, but in some kind of representation, for example, in a representation for a machine or in a representation for a person. It’s difficult, as for me, and it’s confusing, because state is just what is missing in the client-server relationship in the REST architecture. I would call something like "Standardized Data Operations", just first you need to come up with something, and then choose a bright name. And Fielding, in his dissertation, admits that the name was not invented to make it clear what it was about, but "is intended to evoke an image of how a well-designed Web application behaves." But this is nothing, let’s not be offended by a respected person, we also often formulated everything in theses so that it was as incomprehensible as possible and it was impossible to find fault. There was also a good formulation of the idea in Russian - “presentation of data in a format convenient for the client” . In fairness, it should be noted that while I formulated my arguments about the inconsistency of the name, I saw in it some logic, at least in the English version.
It is important to understand thatREST is not a protocol or standard, but an architectural style . This style has its own principles. Let me copy them from the source I like and comment:
- Give every “thing” an ID.
Very desirable. - Link things together.
For example, in a page (presentation) about the Mercedes C218, it would be nice to add a link to a page specifically about the engine of this model, so that those who wish could immediately go there, and not waste time searching for this page itself. - Use standard methods.
I mean, save your strength and money of the customer, use standard HTTP methods, for example GEThttp://www.example.com/cars/00345
- Resources can have multiple representations.
The same data can be returned in XML or JSON for software processing or wrapped in a beautiful design for viewing by a person. - Communicate statelessly.
Yes, a RESTful service should be like an ideal court - it should not be of interest to the past of the defendant (client) or the future - he simply pronounces the verdict (responds to the request).
The term RESTful (web) service just used just means a service implemented using REST principles. So what gives us following these same REST principles? For starters, I would call simplicity the main advantage of the REST architecture. The simplicity of the idea, the simplicity of developing and adding functionality to RESTful applications. The idea is so simple and universal that it is even difficult to grasp at first. We do not add any new layer to our already multi-layer programmer cake, but simply use the long-recognized standards. Therefore, in order to answer the question about the advantages and disadvantages and to make the analysis more meaningful, I propose moving on to comparing the SOAP and REST approaches.
- SOAP is a whole family of protocols and standards , which directly implies that it is a heavier and more complex option from the point of view of machine processing. Therefore, REST is faster.
- SOAP uses HTTP as a transport protocol, while REST is based on it. This means that all existing developments based on the HTTP protocol, such as server-level caching, scaling, continue to work in the REST architecture, and other means must be sought for SOAP. Instead, SOAP services receive such a mythical property as the ability to work with any transport layer protocol instead of HTTP, however, it often has no more practical benefit than the employees of the Chelyabinsk tube rolling plant from a large number of Wikipedia articles in dead languages .
- It is believed that the development of RESTful services is much simpler. This is probably true if you use Notepad as the main development environment, but using our wonderful development tools, I will allow myself to doubt the validity of this statement.
- The first Google result for the query “REST vs SOAP” focuses on the fact that the REST response can be presented in various formats, and SOAP is bound to XML. This is a really important factor, just imagine calling a service from javascript, the answer to which we definitely want to receive in JSON.
- “REST vs SOAP” can be rephrased to “Simplicity vs Standards” , which is manifested in the fact that for SOAP we have the WSDL protocol for an exhaustive description of a web service that, using all the same wonderful development tools, does the same magic work for us. On the REST side, we have a mysterious and unused WADL protocol, which, in principle, is not needed - it interferes with simplicity.
- The second aspect of the previous paragraph is error handling. In SOAP, it is completely standardized, and REST can use the long-known HTTP error codes (if you were visited by the thought that this is obvious and why I am writing this, then you are carefully reading the article).
- Something to start with, but I have one last. This is one of the key thoughts. SOAP works with operations, and REST works with resources . This fact, combined with the lack of a client state in RESTful services, leads us to the fact that such things as transactions or other complex logic should be implemented “SOAP-no.”
Let me give you a couple of examples to understand the difference between the approaches. The bookmaker ordered a service for working with football statistics. Custom functionality - get a list of matches, get details about a match. For editors - edit (Create, Edit, Delete) the list of matches, edit the details of the match. For such a task, you definitely need to choose the REST approach and get benefits from its simplicity and naturalness in interaction with HTTP. Here we do not need SOAP envelopes, SOAP main post offices and SOAP airmail, which can use any brand of aircraft. We just need to implement the following:
Everything is very simple! Now the example is more complicated. The same bookmaker wanted an API for betting on live matches. This procedure includes numerous checks, for example, whether the bid continues to be relevant, if the coefficient has not changed, or if the maximum bid amount for the market has been exceeded. After this, a money transaction occurs, the results of which are recorded in the primary and backup databases. Only after that the client receives an answer about the success of the operation. It clearly observes the focus on operations, there are increased requirements for security and stability of the application, so it is advisable to use SOAP.
And a couple of tasks in order to feel the topic:
- The football club orders the CMS for details about the players on the opposing team. We need functionality to add player characteristics to simple users right during the match, followed by integration with the stadium scoreboard, on which you need to display comments in real time.
- Mexican drug lord Pedro Gonzalez orders an API to track heroin sales in the Southwestern United States. He especially asks the mobile application for this task, because his business often takes place outdoors, where there are no other options for accessing the network.
- An anonymous billionaire really wants a program that would show him all his mistresses in the city in which he is now located and what the current status of the relationship is. He wants to integrate this program with his personal desktop application for selecting places to stay, he really wants a big red text about possible troubles in the window, which offers options for air travel.
What approaches would you use in these tasks?
I also wanted to write about the fact that all this gives the .NET developer and how to use it for my own purposes, but I see that the article’s tediousness index is approaching critical, so I’ll round out. In order to lower the same indicator, I deliberately avoided security aspects and, for example, answering the question “How is authentication possible in the REST architecture, if the reader throughout this article was told that the RESTful service should be stateless?”
And the conclusions of the article will be as follows:
- Fielding with his REST principles did not invent anything , but simply put together in one dissertation what already existed in some form and outlined how to get the maximum benefit from the already formed network architecture.
- SOAP and REST are not competitors . They represent different weight categories and it is unlikely that there will be a task for which it will be difficult to say which approach is more rational to use - SOAP or REST. Therefore, “religious” beliefs in the choice of architecture for a web service are unlikely to be useful. For those who do not know where to start the analysis of the task, I can recommend this presentation. They often win REST.