REST vs SOAP. Part 1. Feel the difference
Some time ago I was googling 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, whether I did not feel the basic idea, or 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, at the same time writing a useful article on this subject.
REST vs SOAP. Part 1. Feel the difference.
REST vs SOAP. Part 2. How easier and more efficient to organize communication platforms?
A couple of months ago, in a cursory study of the issue, I understood about the following about REST:
It was with such memories that I began to surf the Internet. The first thought was, why was the name REST chosen? Representational State Transfer, in the translation of Wikipedia, the “transfer of the state of representation” ... No picture in the head emerges even during the fourth reading. Here they are trying to answer my question and even cite how Roy Fielding (the person who formulated the principles of REST) himself explained the origin of the name. The idea is that the request for a resource from the server transfers the client application to a certain state (state), and the request for the next resource changes the state of the application (transfer). And “Representational” means that the resource is returned for a reason, and in some kind of representation, for example, in a representation for a car or in a presentation for a person. It is difficult, as for me, and confusing, because state is exactly what is missing in the client-server relationship in the REST architecture. I would call something like “Standardized data handling” , but you first need to think of something, and then choose a bright name. In his dissertation, Fielding confesses that the name was not invented so that it was clear what this was about, but “it’s a well-designed Web application behaves.” But this is nothing, we will not be offended by a respected person, we also often formulated everything in diploma works so that it was as incomprehensible as possible and it was impossible to complain. There was also a good wording of the idea in Russian - “data presentation in a format convenient for the client” . To be fair, it should be noted that while I formulated my arguments about the illogicality of the name, I saw in it some logic, at least in the English version.
It is important to understand that REST is not a protocol and not a standard, but an architectural style . This style has its own principles. Let me copy them from the source you like and comment:
The term RESTful (web) service that has just been used only means a service implemented using REST principles. So what gives us following these very principles of REST? For starters, I would call simplicity a major 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 catch it first. We do not add any new layer to our already multi-layered programmer pie, but simply use the standards that have long been recognized. Therefore, in order to answer the question about the advantages and disadvantages and to make the analysis more meaningful, I propose to go over to a comparison of the SOAP and REST approaches.
')
I will give a couple of examples to understand the difference between the approaches. The bookmaker office has ordered a service for working with football statistics. User functionality - get a list of matches, get details about the match. For editors - edit (Create, Edit, Delete) match list, edit match details. For such a task, one definitely needs to choose the REST approach and get the benefits from its simplicity and naturalness in interaction with HTTP. We do not need here SOAP envelopes, SOAP-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 live betting. This procedure includes numerous checks, for example, whether the bet is still up to date, whether the odds have changed, whether the maximum bet amount for the market has not been exceeded. After this, a monetary transaction takes place, the results of which are recorded in the main and standby databases. Only after that the client receives an answer about the success of the operation. There is a clear focus on operations, there are increased requirements for the security and stability of the application, so it is advisable to use SOAP.
And a couple more 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 their own purposes, but I see that the article's boredom index is approaching a critical one, so I’ll round out. In order to lower the same indicator, I deliberately avoided security aspects and, for example, answered the question “How can authentication in REST architecture be possible if the reader was told throughout the entire article that the RESTful service should be stateless?”.
And the conclusions of the article will be as follows:
The contents of a series of articles:
REST vs SOAP. Part 1. Feel the difference.
REST vs SOAP. Part 2. How easier and more efficient to organize communication platforms?
A couple of months ago, in a cursory study of the issue, I understood about the following about REST:
- Everything is a resource with a unique identifier (URL)
- All client operations with the stateless server, i.e. the server should not store any information about the client at all - no session
- All requests can be divided into 4 types in accordance with the CRUD , with each type being assigned an HTTP method - Post, Get, Put and Delete
- All logic revolves around resources, not operations.
It was with such memories that I began to surf the Internet. The first thought was, why was the name REST chosen? Representational State Transfer, in the translation of Wikipedia, the “transfer of the state of representation” ... No picture in the head emerges even during the fourth reading. Here they are trying to answer my question and even cite how Roy Fielding (the person who formulated the principles of REST) himself explained the origin of the name. The idea is that the request for a resource from the server transfers the client application to a certain state (state), and the request for the next resource changes the state of the application (transfer). And “Representational” means that the resource is returned for a reason, and in some kind of representation, for example, in a representation for a car or in a presentation for a person. It is difficult, as for me, and confusing, because state is exactly what is missing in the client-server relationship in the REST architecture. I would call something like “Standardized data handling” , but you first need to think of something, and then choose a bright name. In his dissertation, Fielding confesses that the name was not invented so that it was clear what this was about, but “it’s a well-designed Web application behaves.” But this is nothing, we will not be offended by a respected person, we also often formulated everything in diploma works so that it was as incomprehensible as possible and it was impossible to complain. There was also a good wording of the idea in Russian - “data presentation in a format convenient for the client” . To be fair, it should be noted that while I formulated my arguments about the illogicality of the name, I saw in it some logic, at least in the English version.
It is important to understand that REST is not a protocol and not a standard, but an architectural style . This style has its own principles. Let me copy them from the source you like and comment:
- Give every “thing” an ID.
Ochchchen desirable. - Link things together.
For example, in the page (presentation) of the Mercedes C218 it would be good to add a link to the page specifically about the engine of this model, so that those who wish can immediately go there and not waste time searching for this very page. - Use standard methods.
Means, save your forces and money of the customer, use standard HTTP methods, for example GEThttp://www.example.com/cars/00345
to get data instead of defining your own methods like getCar? id = 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 human viewing. - Communicate statelessly.
Yes, the RESTful service should be like an ideal court - it should not be interested in the past of the defendant (client), nor in the future - he just passes the sentence (responds to the request).
The term RESTful (web) service that has just been used only means a service implemented using REST principles. So what gives us following these very principles of REST? For starters, I would call simplicity a major 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 catch it first. We do not add any new layer to our already multi-layered programmer pie, but simply use the standards that have long been recognized. Therefore, in order to answer the question about the advantages and disadvantages and to make the analysis more meaningful, I propose to go over to a comparison of the SOAP and REST approaches.
')
- SOAP is a whole family of protocols and standards , from which it directly follows that this is a more heavy and complex option in terms 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 practices based on the HTTP protocol, such as server-level caching, scaling, continue to work in the REST architecture as well, and for SOAP you need to look for other tools. Instead, SOAP services get such a mythical property as the ability to work with any transport protocol instead of HTTP, but it’s often not much more practical than the number of wikipedia articles in dead languages than the employees of the Chelyabinsk Pipe Rolling Plant .
- It is believed that the development of RESTful services is much easier. Probably, this is true, if you use Notepad as the main development environment, but using our wonderful development tools, I allow myself to doubt the correctness of this statement.
- The first Google result for the “REST vs SOAP” request 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, it’s enough to imagine a service call from javascript, the answer to which we definitely want to receive in JSON.
- “REST vs SOAP” can be rephrased in “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, which using almost all the same wonderful development tools will magically do almost all work for us. On the REST side, we have a mysterious and unused WADL protocol, which, in principle, is not needed - it prevents simplicity.
- The second aspect of the previous paragraph is error handling. In SOAP, it is fully standardized, and REST can use the long-known HTTP error codes (if you had a thought here that this is obvious and why I am writing this, then you are carefully reading the article).
- This is where one could start, but I’ve saved it for last. This is one of the key thoughts. SOAP works with operations, and REST works with resources . This fact, coupled with the lack of client state in RESTful services, leads us to the fact that such things as transactions or other complex logic must be implemented "SOAP-no."
I will give a couple of examples to understand the difference between the approaches. The bookmaker office has ordered a service for working with football statistics. User functionality - get a list of matches, get details about the match. For editors - edit (Create, Edit, Delete) match list, edit match details. For such a task, one definitely needs to choose the REST approach and get the benefits from its simplicity and naturalness in interaction with HTTP. We do not need here SOAP envelopes, SOAP-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 live betting. This procedure includes numerous checks, for example, whether the bet is still up to date, whether the odds have changed, whether the maximum bet amount for the market has not been exceeded. After this, a monetary transaction takes place, the results of which are recorded in the main and standby databases. Only after that the client receives an answer about the success of the operation. There is a clear focus on operations, there are increased requirements for the security and stability of the application, so it is advisable to use SOAP.
And a couple more tasks in order to feel the topic:
- The football club orders a CMS for detailed information about the players of the enemy team. We need the functionality of adding player characteristics by simple users right during the match, followed by integration with the scoreboard of the stadium, where you need to display comments in real time.
- Mexican drug lord Pedro Gonzalez orders an API to account for heroin sales in the Southwestern states of the United States. He specifically requests a mobile application for this task, since His business often takes place outdoors, where there are no other options for access to the network.
- An anonymous billionaire really wants a program that would show him all his mistresses in the city in which he is now and what is the current status of the relationship. He wants to integrate this program with his already existing personal desktop application for the selection of places to rest, he really wants a big red inscription about possible troubles in the window, where air travel options are offered.
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 their own purposes, but I see that the article's boredom index is approaching a critical one, so I’ll round out. In order to lower the same indicator, I deliberately avoided security aspects and, for example, answered the question “How can authentication in REST architecture be possible if the reader was told throughout the entire article that the RESTful service should be stateless?”.
And the conclusions of the article will be as follows:
- Fielding with his principles REST invented nothing , but simply collected in one thesis what already existed in some form and outlined how you can get the maximum benefit from the already formed network architecture.
- SOAP and REST are not competitors . They represent different weight categories and there is hardly 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 analyzing the task, I can recommend this presentation. They often win REST.
Source: https://habr.com/ru/post/131343/
All Articles