SOAP vs REST (differences)

Question

I have read articles about the differences between SOAP and REST as a web service communication protocol, but I think that the biggest advantages for REST over SOAP are:

1. REST is more dynamic, no need for creating and updating UDDI.

2. REST is not restricted to XML format. REST web services can send plain text, JSON, and also XML.

But SOAP is more standardized (Ex; security).

So, am I correct in these points?

Answer 1

First of all: In the loose sense, web service means using the HTTP protocol to transfer data instead of web pages. However, in the strict sense, a web service, as defined by W3C is a very specific form of that idea. So, when people talk about SOAP vs. REST, they actually mean web services vs. REST (where "web services" refers to the official definition, since, in practice, REST services are also called web services by everyone).

So, let's say you want to call a function in a remote computer, implemented in some other programming language (remote procedure call/RPC). You have to (somehow) send it a message, and get some response. First, that function can be found at a specific URL, provided by its creator. Then, there are two main questions to consider.

• what is the format of the message you should send
• how should the message be carried back and forth

According to the official definition, the answer to the first question is the WSDL, an XML which describes, in detailed and strict format, what are the parameters, what are their types, names, default values, the name of the function to be called, etc. To the second question, there are various answers. The most popular (by far) is SOAP. Its main idea is: wrap the previous XML (the actual message) into yet another XML, and send it over HTTP (although, in theory, it can be used with other protocols, but noone ever does it). The POST method of the HTTP is used to send the message, since there is always a body.

So, by the approach (widely, but erroneously) called SOAP, you map a URL to a function, that is an action. The RESTful approach is: instead of the URL representing an action, it should represent a thing (called resource in the RESTful lingo). Since the HTTP protocol (which we are already using) supports verbs, use those verbs to specify what actions to perform on the thing.

So, with the SOAP (again, wrong term) approach, if you have a list of customers, and you want to view/update/delete one, you will have 3 URLS:

• myapp/read-customer and in the body of the message, pass the id of the customer to be read.
• myapp/update-customer and in the body, pass the id of the customer, as well as the new data
• myapp/delete-customer and the id in the body

While, with the REST approach, you would only have myapp/customers/3 (where 3 is the id of a specific customer). To view the customer data, you hit the URL with a GET request. To delete it, the same URL, with a DELETE verb. To update it, again, the same URL with a POST verb, and the new content in the request body.

For more details about the requirements that a service has to fulfil to be considered truly RESTful, see the Richardson maturity model. The article gives examples, and, more importantly, explains why a (so-called) SOAP service, is a level-0 REST service (although, level-0 means low compliance to this model, it's not offensive, and it is still useful in many cases).

Answer 2

REST vs SOAP is not the right question to ask.

REST, unlike SOAP is not a protocol.

REST is an architectural style and a design for network-based software architectures.

REST concepts are referred to as resources. A representation of a resource must be stateless. It is represented via some media type. Some examples of media types include XML, JSON, and RDF. Resources are manipulated by components. Components request and manipulate resources via a standard uniform interface. In the case of HTTP, this interface consists of standard HTTP ops e.g. GET, PUT, POST, DELETE.

@Abdulaziz's question does illuminate the fact that REST and HTTP are often used in tandem. This is primarily due to the simplicity of HTTP and its very natural mapping to RESTful principles.

Fundamental REST Principles

Client-Server Communication

Client-server architectures have a very distinct separation of concerns. All applications built in the RESTful style must also be client-server in principle.

Stateless

Each client request to the server requires that its state be fully represented. The server must be able to completely understand the client request without using any server context or server session state. It follows that all state must be kept on the client.

Cacheable

Cache constraints may be used, thus enabling response data to be marked as cacheable or not-cacheable. Any data marked as cacheable may be reused as the response to the same subsequent request.

Uniform Interface

All components must interact through a single uniform interface. Because all component interaction occurs via this interface, interaction with different services is very simple. The interface is the same! This also means that implementation changes can be made in isolation. Such changes, will not affect fundamental component interaction because the uniform interface is always unchanged. One disadvantage is that you are stuck with the interface. If an optimization could be provided to a specific service by changing the interface, you are out of luck as REST prohibits this. On the bright side, however, REST is optimized for the web, hence incredible popularity of REST over HTTP!

The above concepts represent defining characteristics of REST and differentiate the REST architecture from other architectures like web services. It is useful to note that a REST service is a web service, but a web service is not necessarily a REST service.

See this blog post on REST Design Principles for more details on REST and the above stated bullets.

EDIT: update content based on comments

Answer 3

IMHO you can't compare SOAP and REST where those are two different things.

SOAP is a protocol and REST is a software architectural pattern. There is a lot of misconception in the internet for SOAP vs REST.

SOAP defines XML based message format that web service-enabled applications use to communicate each other over the internet. In order to do that the applications need prior knowledge of the message contract, datatypes, etc..

REST represents the state(as resources) of a server from an URL.It is stateless and clients should not have prior knowledge to interact with server beyond the understanding of hypermedia.

Answer 4

Addition for:

++ A mistake that’s often made when approaching REST is to think of it as “web services with URLs”—to think of REST as another remote procedure call (RPC) mechanism, like SOAP, but invoked through plain HTTP URLs and without SOAP’s hefty XML namespaces.

++ On the contrary, REST has little to do with RPC. Whereas RPC is service oriented and focused on actions and verbs, REST is resource oriented, emphasizing the things and nouns that comprise an application.