ChatGPT解决这个技术问题 Extra ChatGPT

Compare and contrast REST and SOAP web services? [duplicate]

This question already has answers here: Representational state transfer (REST) and Simple Object Access Protocol (SOAP) (14 answers) Closed 9 years ago.

I currently figure out the similar is both using internet protocol (HTTP) to exchange data between consumer and provider.

The difference is:

SOAP is a XML-based message protocol, while REST is an architectural style SOAP uses WSDL for communication between consumer and provider, whereas REST just uses XML or JSON to send and receive data SOAP invokes services by calling RPC method, REST just simply calls services via URL path SOAP doesn't return human readable result, whilst REST result is readable with is just plain XML or JSON SOAP is not just over HTTP, it also uses other protocols such as SMTP, FTP, etc, REST is over only HTTP

That's everything I know as the differences between them. Could anyone correct me and add more.

They're uncomparable at least because SOAP is a protocol and REST is a concept with no defined spec at all. Nothing prohibits one from writing a SOAP web service compatible with REST.
(1) "SOAP is a XML-based message protocol" (2) "SOAP doesn't return human readable result" --- Conclusion: XML is not human readable. But it clearly is ... fair to say that one of the premises must be wrong?

C
Community

SOAP uses WSDL for communication btw consumer and provider, whereas REST just uses XML or JSON to send and receive data

WSDL defines contract between client and service and is static by its nature. In case of REST contract is somewhat complicated and is defined by HTTP, URI, Media Formats and Application Specific Coordination Protocol. It's highly dynamic unlike WSDL.

SOAP doesn't return human readable result, whilst REST result is readable with is just plain XML or JSON

This is not true. Plain XML or JSON are not RESTful at all. None of them define any controls(i.e. links and link relations, method information, encoding information etc...) which is against REST as far as messages must be self contained and coordinate interaction between agent/client and service.

With links + semantic link relations clients should be able to determine what is next interaction step and follow these links and continue communication with service.

It is not necessary that messages be human readable, it's possible to use cryptic format and build perfectly valid REST applications. It doesn't matter whether message is human readable or not.

Thus, plain XML(application/xml) or JSON(application/json) are not sufficient formats for building REST applications. It's always reasonable to use subset of these generic media types which have strong semantic meaning and offer enough control information(links etc...) to coordinate interactions between client and server.

For more details regarding control information I highly recommend to read this: http://www.amundsen.com/hypermedia/hfactor/

Web Linking: https://www.rfc-editor.org/rfc/rfc5988

Registered link relations: http://www.iana.org/assignments/link-relations/link-relations.xml

REST is over only HTTP

Not true, HTTP is most widely used and when we talk about REST web services we just assume HTTP. HTTP defines interface with it's methods(GET, POST, PUT, DELETE, PATCH etc) and various headers which can be used uniformly for interacting with resources. This uniformity can be achieved with other protocols as well.

P.S. Very simple, yet very interesting explanation of REST: http://www.looah.com/source/view/2284


+1 for the last link ("How I explained REST to my wife")
C
Community

In day to day, practical programming terms, the biggest difference is in the fact that with SOAP you are working with static and strongly defined data exchange formats where as with REST and JSON data exchange formatting is very loose by comparison. For example with SOAP you can validate that exchanged data matches an XSD schema. The XSD therefore serves as a 'contract' on how the client and the server are to understand how the data being exchanged must be structured.

JSON data is typically not passed around according to a strongly defined format (unless you're using a framework that supports it .. e.g. http://msdn.microsoft.com/en-us/library/jj870778.aspx or implementing json-schema).

In-fact, some (many/most) would argue that the "dynamic" secret sauce of JSON goes against the philosophy/culture of constraining it by data contracts (Should JSON RESTful web services use data contract)

People used to working in dynamic loosely typed languages tend to feel more comfortable with the looseness of JSON while developers from strongly typed languages prefer XML.

http://www.mnot.net/blog/2012/04/13/json_or_xml_just_decide


protobuf is much more strongly typed than XML!
From the documentation: "..you compile [the data] with protoc, the protocol buffer compiler, to produce code in C++, Java, or Python" - seems very limited. Straight up JSON and SOAP do not suffer these limitations as the entire point is be be language neutral.
@fread2281 protobuf isn't more strongly typed (that's not really a thing). It's a high performance wire protocol that requires compiled code to support the latest format, (@Michael.M) which in practice isn't that different to the limitations of SOAP, where you have to have WSDL and code deployed at each end to cope with latest formats.
S
Shiven

SOAP brings it’s own protocol and focuses on exposing pieces of application logic (not data) as services. SOAP exposes operations. SOAP is focused on accessing named operations, each implement some business logic through different interfaces.

Though SOAP is commonly referred to as “web services” this is a misnomer. SOAP has very little if anything to do with the Web. REST provides true “Web services” based on URIs and HTTP.

By way of illustration here are few calls and their appropriate home with commentary.

getUser(User);

This is a rest operation as you are accessing a resource (data).

switchCategory(User, OldCategory, NewCategory)

REST permits many different data formats where as SOAP only permits XML. While this may seem like it adds complexity to REST because you need to handle multiple formats, in my experience it has actually been quite beneficial. JSON usually is a better fit for data and parses much faster. REST allows better support for browser clients due to it’s support for JSON.


Interesting, this answer is exactly what this Jan 2010 blog post says... almost word for word
"(not data)" = FALSE - the WSDL in SOAP web services provides a very rich and clear description for returned data in/out so that the data can be easily serialized/de-serialized according to the XSD 'contract'. The is the whole reason why it's referred to as a 'DataContract' in .Net/WCF
("SOAP only permits XML") = that doesn't mean that you can't keep the XML markup extremely light and embed any other format, including JSON or base64 encoded data. If you argue that SOAP data must be wrapped in markup (XML) then it's simple enough to retort that JSON also requires it's markup wrappings to get from point A to point B. It's simple enough to consume SOAP web-services JavaScript.
"REST allows for better support for browser clients due to it's support for JSON" = FALSE - older browsers do not support native JSON parsing (stackoverflow.com/questions/891299/…) Making an HTTP request to do a SOAP call via JavaScript has been possible since the days of AJAX. jQuery SOAP is an example of a library that makes it very simple to call a SOAP service from a browser the can run jQuery JavaScript code. Can you specify another way that it's "better" ??