SOAP and REST can’t be compared directly, since the first is a protocol (or at least tries to be) and the second is an architectural style. This is probably one of the sources of confusion around it, since people tend to call REST any HTTP API that isn’t SOAP.
Pushing things a little and trying to establish a comparison, the main difference between SOAP and REST is the degree of coupling between client and server implementations. A SOAP client works like a custom desktop application, tightly coupled to the server. There’s a rigid contract between client and server, and everything is expected to break if either side changes anything. You need constant updates following any change, but it’s easier to ascertain if the contract is being followed.
I think these are the crucial points to understand what REST is about, and how it differs from SOAP:
- REST is protocol independent. It’s not coupled to HTTP. Pretty much like you can follow an ftp link on a website, a REST application can use any protocol for which there is an standardized URI scheme.
- REST is not mapping CRUD to HTTP methods. Read this answer for a detailed explanation on that.
- REST is as standardized as the parts you’re using. Security and authentication in HTTP is standardized, so that’s what you use when doing REST over HTTP.
- REST is not REST without hypermedia and HATEOAS. This means that a client only knows the entry point URI and the resources are supposed to return links the client should follow. Those fancy documentation generators that give URI patterns for everything you can do in a REST API miss the point completely. They are not only documenting something that’s supposed to be following the standard, but when you do that, you’re coupling the client to one particular moment in the evolution of the API, and any changes on the API have to be documented and applied, or it will break.
- REST is the architectural style of the web itself. When you enter Stack Overflow, you know what a User, a Question and an Answer are, you know the media types, and the website provides you with the links to them. A REST API has to do the same. If we designed the web the way people think REST should be done, instead of having a home page with links to Questions and Answers, we’d have a static documentation explaining that in order to view a question, you have to take the URI
stackoverflow.com/questions/<id>, replace id with the Question.id and paste that on your browser. That’s nonsense, but that’s what many people think REST is.
This last point can’t be emphasized enough. If your clients are building URIs from templates in documentation and not getting links in the resource representations, that’s not REST. Roy Fielding, the author of REST, made it clear on this blog post: REST APIs must be hypertext-driven.
With the above in mind, you’ll realize that while REST might not be restricted to XML, to do it correctly with any other format you’ll have to design and standardize some format for your links. Hyperlinks are standard in XML, but not in JSON. There are draft standards for JSON, like HAL.
Finally, REST isn’t for everyone, and a proof of that is how most people solve their problems very well with the HTTP APIs they call REST and never venture beyond that. REST is hard to do sometimes, especially in the beginning, but it pays over time with easier evolution on the server side, and client’s resilience to changes. If you need something done quickly and easily, don’t bother about getting REST right. It’s probably not what you’re looking for. If you need something that will have to stay online for years or even decades, then REST is for you.
- Since REST uses standard HTTP it is much simpler in just about ever way.
- REST permits many different data formats where as SOAP only permits XML.
- REST allows better support for browser clients due to it’s support for JSON.
- REST has better performance and scalability. REST reads can be cached, SOAP based reads cannot be cached.
- If security is not a major concern and we have limited resources. Or we want to create an API that will be easily used by other developers publicly then we should go with REST web services.
- WS-Security: While SOAP supports SSL (just like REST) it also supports WS-Security which adds some enterprise security features.
- WS-AtomicTransaction: Need ACID Transactions over a service, you’re going to need SOAP.
- WS-ReliableMessaging: Rest doesn’t have a standard messaging system and expects clients to deal with communication failures by retrying.
- SOAP is highly secure as it defines its own security.
- If the security is a major concern and the resources are not limited then we should use SOAP web services. Like if we are creating a web service for banking related work then we should go with SOAP as here high security is needed.
When data is sent over the Internet, each unit transmitted includes both header information and the actual data being sent. The header identifies the source and destination of the packet, while the actual data is referred to as the payload. In general, payload is the data that is carried on behalf of an application and the data received by the destination system.
is a generalization of hypertext for content other than HTML. You can say hypertext is a subset of hypermedia. Hypermedia can be HTML in a browser, with all links, buttons and everything that’s rendered so you can browse a website, or it can be a XML or JSON document intended to be parsed by an automated client who will also follow links and actions like a human would do with a browser, clicking rendered links and buttons.
means the interaction of a client with a REST application must be driven by hypermedia, or to put it simply, the client should obtain all URIs for every resource it needs by following links in the representation of resources themselves, not by relying on out-of-band information, like URI patterns given in documentation, as many APIs do.
This is simpler than it sounds. It just means that the interaction between a client and a REST application should be exactly like a human browsing a website. Take Stack Overflow itself for example. There are Users, Questions and Answers. When you want to see a list of your questions, you don’t go to a documentation website, get an URI template for listing your questions, fill a placeholder with your user id and paste it on your brownser. You simply click on a link to another document described as the list of questions, and you don’t even care about what the exact URI is. That’s what HATEOAS means in practice.