When implementing online billing software, I asked the responsible company if the REST version of the API existed.
The answer was that they did not use REST because of security, that SOAP would be safer because it is software that handles financial information.
Would this be true information? If yes, in what context SOAP is more secure than REST and vice versa?
As for security, I see only one difference between REST and SOAP.
In REST, security is only made at the transport layer, whether using SSL or TSL. SOAP also gives you this option.
However, following the SOAP specification, you can use WS-Security , in this case the protection is not made at Transport level, but the message itself will be encrypted.
But understand, REST does not implement message security simply because it does not make sense in a Web environment, just as it will only give you extra protection only in very specific scenarios.
If you'd like to read more, visit the following site: link
EDIT
I've seen a lot of people putting the advantage of SOAP in the fact that it validates the message, you can do the same in REST, either using a JSON Schema , XML Schema or even Protocol Buffer .
SOAP has more bureaucracy than REST.
Basically the difference is that in SOAP, all data types have to be pre-defined in the interface contract - so the SOAP layer itself will already issue an error if it is sent a list where there should be a string (if SOAP has list).
In REST, payload can be any JSON - and eventually a check has to be done in the application itself for some of the data arriving in JSON, otherwise it will malfunction .
As a concrete example, this happened in a project where I was: the front end sent a list, where in the backend we expected a string, and this caused a mistake in the view.
But realize that if the project was being done with proper testing and documentation this would not have happened - and also that this particular error did not present any security danger. In general REST frameworks allow you to specify field validation - this is just not required. With the specified fields not the difference in security or reliability of the application.
On the other hand, the weight of the specs of each view, and the redundant data in each payload SOAP, make it a very bad protocol to work on almost any issue. There are many other ways to validate data in addition to replicating the payload specification everywhere using XML.
The answer was that they did not use REST due to security [...] Is this information true?
No.
The SOAP specification only defines a data exchange protocol.
The Web Services Interoperability Consortium (WS-I) has created a specification called WS-I Basic Profile , which suggests implementing SOAP under HTTPS to provide security via encryption.
However, the same security can be used in services that use JSON as a data exchange protocol.
It does not make sense to compare, simple as that.
REST defines a set of good practices that should be followed when doing a web application. The protocol used at the application level is HTTP (S). It does not specify or depend on any form of data representation.
SOAP is a data representation protocol. It does not depend on a form of transport, although it is common to use TCP / HTTP or RPC.
In other words, nothing prevents you from doing a RESTfull application where data is represented in SOAP.
One way to ensure security is to use a transport / application protocol designed for this, eg HTTPS.
In general people have the feeling that using SOAP is safer than REST for the following reasons (IMO):
Since REST is not a protocol, it is a kind of "architectural style" of exchanging messages that does not define how the content of the message will be. You can even put all XML of SOAP within the body of a REST message. =)
For this reason, it has become lighter and less complicated to implement and this makes its adoption easier in the case of a new system. The obligation of XML in SOAP causes it to become "heavy" because you end up carrying more control than given, depending on the message. By having more "control", you get that impression of being more trustworthy. That being so, the fact that you say that your system uses REST , by common sense, does not bring reliability. You need to add other technologies in your speech to convince people.
But, for example, if you are the developer of both messages, you are not required to add the SOAP security extension when using the protocol, that is, you can use SOAP with no layer and even so it is likely that people's common sense will make them not question you about it.
