137
- What are the main differences between these types of Web Service?
- In which cases apply?
- Is there any difference in performance?
3 answers
155
SOAP
SOAP is an XML format message transfer protocol for use in distributed environments. The SOAP standard works as a framework type that allows interoperability between multiple platforms with custom messages.
Applying this standard in Web Services, WSDL is generally used to describe the structure of SOAP messages and possible actions in a endpoint.
One of the biggest advantages of this is that many languages and tools can read and generate messages easily. Multiple programming languages allow the generation of domain objects, Stubs and Skeletons from the WSDL setting, allowing remote communication via PRC calls to remote methods, including complex arguments, as if they were called local.
The problem with this pattern is that it adds a overhead considerable, both for being in XML and for adding many metadata tags. In addition, serialization and deserialization of messages can consume considerable time.
REST
REST is another communication protocol, based on the HTTP hypermedia protocol. But it does not impose restrictions on the format of the message, only on the behavior of the components involved.
The biggest advantage of the REST protocol is its flexibility. The developer can choose the most suitable format for the system messages according to their specific need. The most common formats are JSON, XML and plain text, but in theory any format can be used.
This leads us to another advantage: almost always web services that use REST are more "lightweight" and therefore faster.
The problem with REST may arise precisely because of its advantages. As the definition of the data body is entirely up to the developer, interoperability problems are more common.
SOAP OR REST?
Warning: This is a pragmatic opinion.
In general, SOAP is a good option for institutions with rigid standards and complex environments (multiple platforms and systems). Many corporate tools (such as ESB) take advantage of the standard and make it possible to filter, queue, sort and redirect messages exchanged between systems.
Otherwise, for everyday use, I see no concrete reasons not to use REST and JSON. Virtually all modern platforms and languages I know support these concepts and the final solution is much simpler than the SOAP equivalent.
In addition, integrations with high-volume requests are not feasible in SOAP. REST is capable of meeting volume and complexity without difficulties, requiring only a minimum of developer experience to establish and enforce appropriate standards.
47
XML is a type of document, it is not a type of Webservice, and it is used by the SOAP method for message exchange.
The following text was taken from: http://www.infoq.com/br/articles/rest-soap-when-to-use-each
REST makes use of a standard URI (Uniform Resource Identifier), making a call to a web service as in: http://www.minhaempresa.com.br/programa/metodo?Parametros=xx
REST is simple to understand and can be adopted on virtually any client or server with HTTP/HTTPS support. The developers who use it cite as main advantages the ease of development, the use of existing web infrastructure and a small learning effort.
On the other hand, SOAP, the grandfather of web service interfaces, will not stop being used anytime soon. With SOAP v 1.2, many of the perceived deficiencies in this technology have been corrected and increased ease of use. In addition, the acronym SOAP no longer represents "Simple Object Access Protocol". In W3C Specification 1.2, SOAP is only the specification name.
Using SOAP 1.2 brings an additional load not found when using REST, but there are also advantages. First SOAP is based on XML, in three ways: the envelope, which defines the content of the message and tells how to process it; a set of coding rules for the data types; and the layout for the call and response procedures. This "envelope" is sent via (for example) HTTP/HTTPS. And an RPC (Remote Procedure Call) is executed, and the envelope returns with the formatted XML document information.
One of the advantages of SOAP is the use of a "generic" transport method. While REST makes use of HTTP/HTTPS, SOAP can use any existing means of transport to send your request, from SMTP to even JMS (Java Messaging Service). However, a perceived disadvantage in the use of XML is its prolific nature and the time needed to analyze the displayed result.
But an untold story is that both technologies can be mixed and combined. REST is easy to understand and extremely accessible but lacking standards, and the technology is considered only an architectural approach. In comparison, SOAP is an industry standard, with well-defined protocols and a set of well-established rules.
It can be stated, then, that cases where REST works well are:
Resource and bandwidth constraint situations: A return structure is in any format defined by the developer and any browser can be used. This is because the REST approach uses the call pattern GET, PUT, POST and DELETE. REST can also use Xmlhttprequest objects (the basis of the old AJAX) that most modern browsers supports.
Totally Stateless Operations: Whether an operation needs to be continued, REST will not be the best option. However, if they are required stateless CRUD operations (Create, Read, Update and Delete), REST would be the best alternative.
Situations that require caching: whether information can be stored in cache, due to the nature of stateless REST operation, that would be a appropriate scenario for the technology.
These three situations cover many solutions. So why do we still need to consider using SOAP? Again, SOAP is quite mature and well defined and comes with a complete specification. The REST approach is just that: an approach. Is fully open. So when you find one of the situations below, SOAP can be a great solution:
Asynchronous processing and calling: if the app needs a guaranteed level of reliability and safety for the exchange of messages, then SOAP 1.2 offers additional standards for this type operation such as WSRM (WS-Reliable Messaging).
Formal contracts: if both sides (supplier and consumer) have to agree to the data exchange format, then SOAP 1.2 provides rigid specifications for this type of interaction.
stateful operations: in case the application needs information contextual and state management with coordination and security, the SOAP 1.2 has an additional specification in its supporting structure that need (security, transactions, coordination, etc.). Comparatively, using REST would require developers build a customized solution.
As it turns out, each of the approaches has its usefulness. Both have security issues, transport layers, etc.; but both can do the necessary work and bring their contribution to the development of web applications.
Taken from: http://www.infoq.com/br/articles/rest-soap-when-to-use-each
10
Short answer
SOAP is old-fashioned, complicated and boring. In some languages, SOAP support is getting decadent, there are libraries that work but have not been played for almost 10 years.
REST (and Graphql) are more modern, easier to use, there is plenty in libraries, documentation, examples and usually uses JSON.
XML is also quite obsolete against JSON as a data exchange format. SOAP is based on XML.
The only marginally interesting thing about SOAP is WSDL, which is a "schema" provided by every SOAP server. In a way the SOAP API is self-documented by the WSDL, but I don’t think it counterbalances the REST, and there is already "JSON schema" if you make a point of having schema.
SOAP has a whole scheme of defining simple and compound types with constraints in WSDL itself, it is the kind of thing that seems interesting a priori, but in practice it is an unnecessary complication. The simple composition of simple types made by JSON is extremely practical.
-
3
For those curious who come here, about Graphql vs REST: https://answall.com/q/226340/64969
Browser other questions tagged web-service
You are not signed in. Login or sign up in order to post.
The use of HTTP standard methods 1.1 (get, post, put and delete...) can be considered an advantage in REST?
– humungs
@Ricardogiaviti It doesn’t seem like an advantage, it’s more like a feature or a restriction. SOAP also works over HTTP, although this is covered by the protocol layers.
– utluiz
@Ricardogiaviti Actually, on second thought, the fact that REST only uses HTTP makes it simpler, lighter, more efficient and compatible than SOAP, which requires more layers of complexity. However, as for using the standard HTTP methods, this seems to me more of a feature. It would be like saying that a car is better than a bike because it has 4 wheels.
– utluiz
I always had this doubt, but I think this is slightly an advantage because it was not necessary to "reinvent the wheel" with new protocol specifications, for example. It is already used "ready" and still maintained by a serious organization.
– humungs
@utluiz, his reply was so good that it was copied: http://blog.developmentwith/differca-entresoap-e-rest/
– Taisbevalle
@Taisbevalle Thanks for the warning. I have no problems with this, beyond what the license of the site allows. In fact, it’s a good sign that something I wrote so long ago is having such an impact. : D
– utluiz
What I don’t understand is: REST is not a protocol but SOAP is. I understand that REST is just an abstraction and is not a protocol, because who does the communication between 2 systems in this case is the HTTP protocol. The point is, SOAP also uses other protocols for message transport, so why is it considered protocol?
– Filipe Moraes
@Filipemoraes REST is a protocol in the sense that it defines well-defined characteristics for communication between two parties, even if it is not as strict a definition as SOAP. What you are confusing is that there are different protocols at different levels gives communication. Have you studied "Computer Networks"? There you learn, among other things, that the IP protocol acts on one layer, TCP on another, HTTP on another. Now, on top of that, add REST or SOAP to a higher level.
– utluiz
I understand, then, that to say that REST is not a protocol in every sense is a false statement, because in the REST specification itself it is called a protocol: https://www.w3.org/2001/sw/wiki/REST . Thanks for the clarification.
– Filipe Moraes
The problem of interoperability in REST could be solved with the JSON Schema. I know I am "resurrecting" an old question, but it is very useful and be the case, could be completed.
– Filipe Moraes
@Filipemoraes Yes, you can solve the problem gives interoperability by adopting a standard for content gives communication. Although this is important in practice, in fact it is also important that it is not part of the REST standard, because it is precisely the flexibility of it that makes it be what is and allows several competing solutions, such as Jsonb is Protobuf, in addition to the ones that you mentioned.
– utluiz
@Filipemoraes As for completing the answer, I think it would be a bit off-topic. Ideally, ask another, more specific question. Feel free to do this.
– utluiz
REST is a protocol? Wouldn’t it be an architectural style?
– Sidon