Is SOAP safer than REST?

Asked

Viewed 1,106 times

27

When implementing online billing software, I asked the responsible company if there was a REST version of the API.

The answer was that they did not use REST due to security, that SOAP would be safer because it is a software that manipulates financial information.

Would that be true? If so, in what context is SOAP safer than REST and vice versa?

  • 2

    Define safe..

  • It is likely that the response you got has to do with the SOAP standard having a well-defined "schema" and each tag/attribute in XML having a function and the security implementation also taking place defined in the message. REST has the "body" of the free message without a mandatory "schema" and the way to authenticate/authorize depends more on the programmer than on the "Protocol" chosen.

  • @bigown confidence, guarantee, stability... I think that was the context in which the company responded, at least that’s what gives the impression.

  • has a question for the OS on this subject, http://stackoverflow.com/questions/853620/secure-web-services-rest-over-https-vs-soap-ws-security-which-is-better

  • 5

    There can be a lot of differences between REST and SOAP. But to say that SOAP is safer than REST is what is popularly called fib, talk-to-sleep or hairy lie. What can happen is to say that "it is easier to ensure safety with SOAP", what then may be true.

  • 1

    Perhaps the person who mentioned security was actually referring to character breaking, spacing, etc. It is very common for people to use the safe word to refer to possible losses by "truncating" something, which I think is a big mistake, because it confuses a lot, especially in IT.

Show 1 more comment

5 answers

18

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 a list is sent where there should be a string (if SOAP has a list).

In REST, the 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 there will be a 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 triggered an error in the view.

But note that if the project was being done with proper testing and documentation this would not have happened - and also that this particular mistake posed no safety risk at all.
In general, REST frameworks allow you to specify field validation - this is just not required. With the specified fields not the difference in safety or reliability of the application.

On the other hand, the weight of specifications of each view, and the redundant data in each payload SOAP, THEY MAKE IT A VERY BAD PROTOCOL TO WORK ON ALMOST ANY TOPIC. There are many other ways to validate data besides replicating the specification of payload everywhere using XML.

  • 2

    Just one observation: in practice who uses REST also uses a JSON payload because it is lighter, but does not have this requirement, could be an XML.

18


As for security, I see only one difference between REST and SOAP.

In REST, security is only done in the transport layer, whether using SSL or TSL. SOAP also gives you this option.

But following the SOAP specification, it is possible to use WS-Security, in this case the protection is not done at the Transport level, but the message itself will be encrypted.

But understand, REST doesn’t implement security about the message simply because it doesn’t make sense in a Web environment, just as it will only give you extra protection in very specific scenarios.

If you want to read more about it, visit the following website.: http://www.topwcftutorials.net/2014/09/transport-level-security-vs-message-level-security-wcf.html

EDIT

I saw many people putting as an advantage of SOAP the fact that it validates the message, it is possible to do the same in REST, either using a JSON Schema, XML Schema or even Protocol Buffer.

  • On the validation of the message, the crucial difference between the two is the mandatory validation of the messages.

10

The answer was that they did not use REST because of the security [...] This would be true information?

Not.

The SOAP specification defines only one data exchange protocol.

The Web Services Interoperability Consortium (WS-I) has created a specification called WS-I Basic Profile, which suggests the implementation of 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.

2

It’s something that makes no sense to compare, just like that.

REST defines a set of best practices that should be followed when making 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.

That is to say nothing prevents you from making a Restfull application in which the data is represented in SOAP.

Rest - wiki

SOAP - wiki

One way to ensure security is to use a transport/application protocol designed for this, for example HTTPS.

1

By common sense, maybe Yes.

In general people have the feeling that using SOAP is safer than REST for the following reasons (IMO):

  • It is an older message format.
  • It has a set of rules that prevent programmers from "reinventing the wheel".
  • It is widely used by the systems they use web services for integration.
  • Have extensions already defined in the protocol to handle message security.
  • Libraries and examples already exist in various programming languages.

Already the REST It’s not a protocol, it’s a kind of "architectural style" of exchanging messages that doesn’t define what the content of the message will look like. You can even put all the XML of SOAP from the body of a message REST. =)

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 the SOAP makes it "heavy" because you end up loaded more control than given, depending on the message. Because you have more "control", you get this impression of being more reliable. As such, the fact that you say your system uses REST, by common sense, does not bring reliability. You need to aggregate other technologies in your speech to convince people.

But, for example, if you are the developer of the two tips of messages, you are not required to add the security extension of the SOAP when using the protocol, that is, you can use SOAP without any layer of security and yet it’s likely that people’s common sense will cause them not to question you about it.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.