The advantages, disadvantages, and use cases between the two ways of creating web services.
As a developer we might have worked with REST as well as SOAP based services. However, when it comes to decide which one to use, many developers are not very clear on the answer. Let’s look at what the differences are in these two ways of creating web services. We’ll look at the REST vs SOAP from a use-case perspective, hopefully making it easier to choose which protocol is better suited for your job.
Before we dig down into the differences here is a short history about REST and SOAP.
REST: REST (REpresentational State Transfer) was introduced and defined in 2000 by Roy Thomas Fielding in his PhD dissertation “Architectural Styles and the Design of Network-based Software Architectures”. Rest facilitates the philosophy of the open web.
SOAP: SOAP (Simple Object Access Protocol) was introduced in 1998 by Dave Winer in collaboration with Microsoft. SOAP is mainly used to address the goals of the enterprise market.
|Makes data available as a resources (nouns). E.g. AccountInformation, Invoice||Makes application logic available as a servies (verb + noun). E.g. getAccountInformation, PayInvoice|
|It’s an architectural style. No strict contract between client and server.||It’s a protocol.|
|Follows the philosophy of the Open Web.||Follows a formal enterprise approach.|
|It uses standard HTTP. Easy to implement and maintain.||Works on top of any communication protocol, even asynchronously|
|Communication isn’t controlled by a single entity||Information about objects is communicated to clients|
|Returns data in many different formats (JSON, XML, etc.)||It can be fully described using WSDL.|
|Better performance and scalability. Reads can be cached.||Provides end-to-end reliability and successful/retry logic is built in.|
|REST allows better support for browser clients due to its support for JSON.||Security and authorization are part of the protocol.|
|Clearly separates client and server implementations|
|Information can be stored by the client to prevent multiple calls|
|Only works on top of HTTP protocol.||Hard to implement and not so popular among web and mobile developers.|
|No built-in standards for security or reliability.||Permits XML data format only.|
|No constraints on the payload.||SOAP defines standards to be strictly followed.|
|Hard to enforce authorization and security on top of it||Requires more bandwidth and resource than REST.|
When to Use What
|When your bandwidth is very limited.||When performing transactions that involve multiple calls.|
|When client and server operates on a web environment.||When you want to enforce a strict contract between client and server|
|When information about objects doesn’t need to be communicated to the client.||When clients need to have access to objects available on servers|
When NOT to Use What
|When you need to enforce a strict contract between client and server||When you want the majority of developers to easily use your API|
|When performing transactions that involve multiple calls||When your bandwidth is very limited|
In nutshell, identify your project need and goal you want to achieve before you pick any of the approaches. The best way to choose between REST and SOAP is by comparing them on a use-case basis. By looking at both their strengths and weakness in certain environments, as well as understanding your own projects scope, you can make the most informed decision.
Use REST if you’re focused on wide scale API adoption or if your API is targeted at mobile apps. Use SOAP if you are dealing with transactional operations and you already have an audience that is satisfied with this technology.