Last modified: June 23, 2017
Comparing SOAP to REST is comparing apples to oranges. SOAP is a protocol while REST is an architectural approach to the web. Despite these fundamental differences, developers are quick to compare SOAP vs REST for web services. While it's true that you can implement a web service using either SOAP or REST, this article explains what makes each "approach" different and the appropriate use case for both.
Representational state transfer (REST) is an architectural approach to writing web services. It describes a specific way of communicating between two computer systems over the internet.
Whenever developers use URL endpoints to hit data services, they are quick to call it a RESTful interface. While this is mostly correct, there are six constraints that make a web service truly "RESTful".
To be RESTful, clients must be decoupled from the servers they communicate with. Clients should be able to develop independently without breaking. Clients send individual resources represented through URIs. The server sends back a formatted message representing underlying database records. In this way, the client is not highly coupled with the server.
In RESTful web services, clients send all information needed for the server to carry out the request. This means the client must resend session state as necessary because the server does not record or communicate state information. The server simply returns information based on the client request URI. It does not remember state directly (even if session data is stored server side using a db store like MongoStore etc).
RESTful responses must be cacheable by web clients.
Similar to the uniform interface principle, the client must be largely decoupled from the service. Clients aren't concerned with data storage or how information is stored or retrieved from the server. Similarly, servers aren't concerned with user state, sessions, etc. They simply returned a response message based on the URI request.
Clients simply hit endpoints. They may be running through a proxy but are indifferent to whether or not they are directly hitting the actual server. This allows for potential "layered" requests to the end service.
Unlike REST, the Simple Object Access Protocol (SOAP) is a protocol for defining web services. SOAP clients are tightly coupled to the server they communicate with. The protocol is transport independent meaning it doesn't rely on HTTP and can be used with other transport layers like SMTP.
SOAP exclusively uses XML to send messages. Using WSDL (web services description language) files, SOAP operations describe the nature of the web service itself. This includes things like the data types used with the web service along with operations that can be performed, etc. This is fundamentally different from REST because the relationship between the client and the server is explicitly defined with each message.
The answer as to which is right for you is overwhelmingly REST. REST provides a faster way to communicate and exchange data between clients and servers and gives you a lot more flexibility with the clients you use. By setting up a REST interface for your app, you can have different clients (native apps, web sites, etc) hit the same REST endpoints, perform the same actions, and return the same responses. With SOAP, you are tied to XML and must specifically address the relationship your client will have with the server it communicates with.
SOAP is a good option for enterprise based projects where security is emphasized. SOAP is highly extensible and defines its own security (versus REST which relies on the underlying transport layer HTTP).
When discussing SOAP vs REST, always remember that the two are fundamentally different. While REST is an architectural approach to web services, SOAP is a specific protocol for communicating between clients and servers. REST provides a more flexible environment with respect to response types and relationships between client/server. SOAP provides a specific yet highly extensible and secure format for building web services.