REST vs SOAP
Update: GraphQL is the new kid on the block. Be sure to check out this comparison to see how GraphQL stacks up to REST and other web service methodologies.
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.
What is REST
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".
Uniform Interface
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.
Stateless
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).
Cacheable
RESTful responses must be cacheable by web clients.
Client-Server
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.
Layered System
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.
Code on Demand
Servers can extend clients by passing executable code. A good example would be a REST call returning executable JavaScript that can then be run by the client.
What is SOAP
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.
Soap vs REST: Which is right for you?
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).
Conclusion
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.
