REST vs SOAP. Part 2. How easier and more efficient to organize communication platforms?
After writing the first part of the article, the appetite broke out and I wanted to continue studying, this time with more attention to the practical part. All the fuss we inflamed because of the need for interaction between applications and platforms, so this is what the article will be mainly devoted to.
REST vs SOAP. Part 1. Feel the difference.
REST vs SOAP. Part 2. How easier and more efficient to organize communication platforms?
Why do we need the interaction of applications, especially written on different platforms? Stupid question, of course. In the programming world, there are in parallel and develop several completely independent, and in some places warring platforms. In addition, a huge amount of software has already been written and is working successfully, so no one will rewrite it for each new platform. Take the bank for an example. All in-house bank programmers have always written on JAVA, so the bank has a service that has been working fine for 5 years, beautiful Android applications have recently appeared that work stably on almost all versions of the OS, and even the site with the applet that teachers in Kharkov universities are still shown as an example of advanced web technologies (jk). And now there is the task of developing a desktop banking application for Windows. The bank ordered a WPF application from an outsourcing company. How to organize communication platforms?
For now, let's digress from the example and turn to history. It's probably more difficult for me to do this than for many of my colleagues, because I joined the sect of programmers in the .Net days, when you don’t need to know the HTTP protocol to write websites, and you can even write full-featured desktop applications without having heard of WinAPI . But I will try to make such an excursion. The times of dinosaurs will not be particularly considered (we will assume that dinosaurs became extinct with the advent of XML in 1998), so as not to move away from the main theme. Suppose we have an established connection between two applications, through which one can send bytes and the other will receive them. What's next? Applications must agree that, for example, "1" means "send a list of all customers", "2 | 36782" - "send a list of transactions for customer 36782". Perhaps something like this happened in the heyday of the Mesozoic Era. This required developers to invent a new bike for each application interaction. With the development of the Internet (mid-90s), applications have been able to exchange information, providing it in a specified form at a specified URL (later it will be called “REST”). What protocols were there and how applications communicated before the advent of XML-RPC — I won’t write, just because I don’t know enough, maybe nostalgic feelings will break through in the comments.
')
RPC is a “remote procedure call”, a very old concept, combining ancient, medium and modern protocols that allow you to call a method in another application. XML-RPC is a protocol that appeared in 1998, shortly after the appearance of XML. Initially supported by Microsoft, but soon Microsoft completely switched to SOAP and therefore in the .Net Framework we will not find classes to support this protocol. Despite this, XML-RPC continues to live in various languages ​​(especially in PHP), apparently, has earned the love of developers for its simplicity. An interesting feeling, when you finally understand what I have long written about in a resume. This is about XML-RPC and my student resume. :)
SOAP also appeared in 1998 through the efforts of Microsoft. It was announced as a revolution in the software world. This is not to say that everything went according to Microsoft’s plan; there was a huge amount of criticism due to the complexity and heavyness of the protocol. At the same time, there were those who considered SOAP to be a breakthrough. The protocol itself continued to evolve and breed with dozens of new and new specifications, until in 2003 the W3C approved SOAP 1.2 as the recommendation, which is now the last one. The SOAP family turned out impressive, here is their family photo:
(in the photo - WS-Addressing, WS-Enumeration, WS-Eventing, WS-Transfer, WS-Trust, WS-Federation, Web Single Sign-On ... And the second one to the right doesn’t remember what the name is)
For more than ten years, the debate over SOAP has not subsided , it is still fiercely criticized for congestion, for its low speed. However, the protocol did not die, rather the opposite, although the world did not conquer either. Protocol criticism is largely fair : HTTP features are not used, the length of messages is longer than that of REST , there is often no benefit from all these WS-Federation and WS-AtomicTransaction.
But I want to focus on something else - how quickly you can develop distributed applications using the SOAP protocol family! Is this not the revolution that Microsoft promised us? In my opinion, it is she. Where else can you add attributes in the code, click the Publish button on the service, click the Generate Proxy button on the client and call the code as if it were in the same project? Therefore, the question of in which languages ​​and programming environments such a fairy tale is possible comes to the fore. I will try to reduce this data to the table:
Despite all the flattering words addressed to SOAP, I'm not going to say that the REST approach is not needed. The term REST appeared in 2000, i.e. only two years later than the first version of SOAP. The approach itself appeared much earlier, in 2000 it was just realized, documented, and the name changed from a long “I give you such and that information there” to an incomprehensible “REST”. The origin of the name and principles of REST were discussed in detail in the first part of the article. Here I will focus on where REST is better to use and why :
And when to use SOAP:
Thus, I have come down to the fact that SOAP should be used where it is supported, otherwise REST should be used . This will significantly reduce the time for developing web-service clients and making changes to them, and instead of analyzing the code and adding new fields there, you can simply click the Update Service Reference button.
The speed of developing REST and SOAP services in .Net is the same. In general, WCF can turn a SOAP service into a RESTful and vice versa by simple and not laborious configuration tricks, therefore, speaking of accelerating development speed, I mean the client part, which can be developed both simultaneously with the server part, and much later another company. The benefits of using SOAP increase if the service accepts and returns large and complex data structures .
Now REST and SOAP are both successfully used, but it may happen that SOAP really disappears, as its critics write. This, in my opinion, is possible if WSDL or a similar protocol will be used for RESTful services, which will allow to generate client proxies. There were such inclinations, the protocol was called WADL, but at the moment nothing like this exists. Of course, such a scenario would require the desire and decent efforts of at least one of the major players in the IT world, but I would not rule out such an option. And then we will have the best of both worlds - simplicity and benefits from the network architecture and automation of application interaction using client proxies.
Everyone has already forgotten about the example from the beginning of the article? He is taken from life. Let me remind you that a WPF application is being developed there that should receive data from an existing service written in JAVA. In what format could it give us data so that everything would look nice in accordance with this article? That's right, in SOAP. And he gives json. I hope no one thought “what json, is this in the sense of REST?”. Of course REST ! REST can return data in plain XML, json, or any other requested format, even in the “as Bob asked” format, if you can of course make this format one of the recommended W3C standards or at least agree with the service developers so that they know what to do with by this:
We are distracted from the case. Well, the service returns the data to json, and how does this threaten us? And this is what: we cannot generate a client proxy, we will have to manually send requests and parse responses. Have to use HttpWebRequest or add-ons above it. And there would be SOAP - the customer's money would be saved.
I hope I managed to describe a fairly complete picture of the interaction of applications, regardless of language and platform. I wanted to add that the three approaches described (REST, XML-RPC, SOAP) are not all possible options. For example, toys for social networks (written in Flex) often establish a direct connection through sockets with the server part written in C #. Due to this, a gain in speed is obtained along with the need to invent a moped for each new application. Somewhere it was already ...
It is possible that I missed something important, especially if it does not concern .Net, I will be glad to know about it.
PS Thank you int03e , SSSurkv and 1nd1go for promoting my karma yesterday so that I can publish this article.
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?
Why all this?
Why do we need the interaction of applications, especially written on different platforms? Stupid question, of course. In the programming world, there are in parallel and develop several completely independent, and in some places warring platforms. In addition, a huge amount of software has already been written and is working successfully, so no one will rewrite it for each new platform. Take the bank for an example. All in-house bank programmers have always written on JAVA, so the bank has a service that has been working fine for 5 years, beautiful Android applications have recently appeared that work stably on almost all versions of the OS, and even the site with the applet that teachers in Kharkov universities are still shown as an example of advanced web technologies (jk). And now there is the task of developing a desktop banking application for Windows. The bank ordered a WPF application from an outsourcing company. How to organize communication platforms?
A bit of history
For now, let's digress from the example and turn to history. It's probably more difficult for me to do this than for many of my colleagues, because I joined the sect of programmers in the .Net days, when you don’t need to know the HTTP protocol to write websites, and you can even write full-featured desktop applications without having heard of WinAPI . But I will try to make such an excursion. The times of dinosaurs will not be particularly considered (we will assume that dinosaurs became extinct with the advent of XML in 1998), so as not to move away from the main theme. Suppose we have an established connection between two applications, through which one can send bytes and the other will receive them. What's next? Applications must agree that, for example, "1" means "send a list of all customers", "2 | 36782" - "send a list of transactions for customer 36782". Perhaps something like this happened in the heyday of the Mesozoic Era. This required developers to invent a new bike for each application interaction. With the development of the Internet (mid-90s), applications have been able to exchange information, providing it in a specified form at a specified URL (later it will be called “REST”). What protocols were there and how applications communicated before the advent of XML-RPC — I won’t write, just because I don’t know enough, maybe nostalgic feelings will break through in the comments.
')
RPC
RPC is a “remote procedure call”, a very old concept, combining ancient, medium and modern protocols that allow you to call a method in another application. XML-RPC is a protocol that appeared in 1998, shortly after the appearance of XML. Initially supported by Microsoft, but soon Microsoft completely switched to SOAP and therefore in the .Net Framework we will not find classes to support this protocol. Despite this, XML-RPC continues to live in various languages ​​(especially in PHP), apparently, has earned the love of developers for its simplicity. An interesting feeling, when you finally understand what I have long written about in a resume. This is about XML-RPC and my student resume. :)
SOAP
SOAP also appeared in 1998 through the efforts of Microsoft. It was announced as a revolution in the software world. This is not to say that everything went according to Microsoft’s plan; there was a huge amount of criticism due to the complexity and heavyness of the protocol. At the same time, there were those who considered SOAP to be a breakthrough. The protocol itself continued to evolve and breed with dozens of new and new specifications, until in 2003 the W3C approved SOAP 1.2 as the recommendation, which is now the last one. The SOAP family turned out impressive, here is their family photo:
(in the photo - WS-Addressing, WS-Enumeration, WS-Eventing, WS-Transfer, WS-Trust, WS-Federation, Web Single Sign-On ... And the second one to the right doesn’t remember what the name is)
For more than ten years, the debate over SOAP has not subsided , it is still fiercely criticized for congestion, for its low speed. However, the protocol did not die, rather the opposite, although the world did not conquer either. Protocol criticism is largely fair : HTTP features are not used, the length of messages is longer than that of REST , there is often no benefit from all these WS-Federation and WS-AtomicTransaction.
But I want to focus on something else - how quickly you can develop distributed applications using the SOAP protocol family! Is this not the revolution that Microsoft promised us? In my opinion, it is she. Where else can you add attributes in the code, click the Publish button on the service, click the Generate Proxy button on the client and call the code as if it were in the same project? Therefore, the question of in which languages ​​and programming environments such a fairy tale is possible comes to the fore. I will try to reduce this data to the table:
But what about REST, is it really not needed?
Despite all the flattering words addressed to SOAP, I'm not going to say that the REST approach is not needed. The term REST appeared in 2000, i.e. only two years later than the first version of SOAP. The approach itself appeared much earlier, in 2000 it was just realized, documented, and the name changed from a long “I give you such and that information there” to an incomprehensible “REST”. The origin of the name and principles of REST were discussed in detail in the first part of the article. Here I will focus on where REST is better to use and why :
- In the services that will be used from javascript . There is nothing to say, javascript works well with json, so it is this that should be provided.
- In services that will be used from languages ​​in which it is not possible to generate a client proxy. This is Objective-C , for example. No need to manually parse the SOAP envelope, there’s no need.
- When there are very high performance requirements . These are usually very intensively used APIs, like Twitter API or Google API.
And when to use SOAP:
- When interaction occurs between platforms for which tools exist to accelerate development using SOAP . For example, correctly write a SOAP service in JAVA that will be used from .Net and Flex.
- When can I benefit from all the SOAP cheating. I have no reliable information that anyone has managed to do this. I can not think of a clear example.
Thus, I have come down to the fact that SOAP should be used where it is supported, otherwise REST should be used . This will significantly reduce the time for developing web-service clients and making changes to them, and instead of analyzing the code and adding new fields there, you can simply click the Update Service Reference button.
The speed of developing REST and SOAP services in .Net is the same. In general, WCF can turn a SOAP service into a RESTful and vice versa by simple and not laborious configuration tricks, therefore, speaking of accelerating development speed, I mean the client part, which can be developed both simultaneously with the server part, and much later another company. The benefits of using SOAP increase if the service accepts and returns large and complex data structures .
Are SOAP days numbered?
Now REST and SOAP are both successfully used, but it may happen that SOAP really disappears, as its critics write. This, in my opinion, is possible if WSDL or a similar protocol will be used for RESTful services, which will allow to generate client proxies. There were such inclinations, the protocol was called WADL, but at the moment nothing like this exists. Of course, such a scenario would require the desire and decent efforts of at least one of the major players in the IT world, but I would not rule out such an option. And then we will have the best of both worlds - simplicity and benefits from the network architecture and automation of application interaction using client proxies.
Example
Everyone has already forgotten about the example from the beginning of the article? He is taken from life. Let me remind you that a WPF application is being developed there that should receive data from an existing service written in JAVA. In what format could it give us data so that everything would look nice in accordance with this article? That's right, in SOAP. And he gives json. I hope no one thought “what json, is this in the sense of REST?”. Of course REST ! REST can return data in plain XML, json, or any other requested format, even in the “as Bob asked” format, if you can of course make this format one of the recommended W3C standards or at least agree with the service developers so that they know what to do with by this:
Content-Type: application/as-Vasya-asked; charset=utf-8
We are distracted from the case. Well, the service returns the data to json, and how does this threaten us? And this is what: we cannot generate a client proxy, we will have to manually send requests and parse responses. Have to use HttpWebRequest or add-ons above it. And there would be SOAP - the customer's money would be saved.
Conclusion
I hope I managed to describe a fairly complete picture of the interaction of applications, regardless of language and platform. I wanted to add that the three approaches described (REST, XML-RPC, SOAP) are not all possible options. For example, toys for social networks (written in Flex) often establish a direct connection through sockets with the server part written in C #. Due to this, a gain in speed is obtained along with the need to invent a moped for each new application. Somewhere it was already ...
It is possible that I missed something important, especially if it does not concern .Net, I will be glad to know about it.
PS Thank you int03e , SSSurkv and 1nd1go for promoting my karma yesterday so that I can publish this article.
Source: https://habr.com/ru/post/134303/
All Articles