Advantages of REST and SOAP. Where to use REST or SOAP?

Advantages of REST

  • Since REST uses standard HTTP, it is much simpler in just about every way. Creating clients, developing APIs, the documentation is much easier to understand, and there aren’t very many things that REST doesn’t do easier/better than SOAP.
  • REST permits many different data formats whereas SOAP only permits XML. While this may seem like it adds complexity to REST because you need to handle multiple formats, in my experience, it has been quite beneficial. JSON usually is a better fit for data and parses much faster. REST allows better support for browser clients due to its support for JSON.
  • REST has better performance and scalability. REST reads can be cached; SOAP-based reads cannot be cached.
  • No expensive tools require interacting with the Web service
  • Smaller learning curve
  • Efficient (SOAP uses XML for all messages, REST can use smaller message formats)
  • Fast (no extensive processing required)
  • Closer to other Web technologies in design philosophy

Advantages of SOAP

  • WS-Security: While SOAP supports SSL (just like REST) it also supports WS-Security which adds some enterprise security features. Supports identity through intermediaries, not just point to point (SSL). It also provides a standard implementation of data integrity and data privacy. Calling it “Enterprise” isn’t to say it’s more secure, it simply supports some security tools that typical internet services do not need for, in fact, they are only needed in a few “enterprise” scenarios.
  • WS-AtomicTransaction: Need ACID Transactions over a service, you’re going to need SOAP. While REST supports transactions, it isn’t as comprehensive and isn’t ACID compliant. Fortunately, ACID transactions almost never make sense over the internet. REST is limited by HTTP itself which can’t provide two-phase commit across distributed transactional resources, but SOAP can. Internet apps don’t need this level of transactional reliability, enterprise apps sometimes do.
  • WS-ReliableMessaging: Rest doesn’t have a standard messaging system and expects clients to deal with communication failures by retrying. SOAP has successful/retry logic built in and provides end-to-end reliability even through SOAP intermediaries.
  • Language, platform, and transport independent (REST requires use of HTTP)
  • Works well in distributed enterprise environments (REST assumes direct point-to-point communication)
  • Standardized
  • Provides significant pre-build extensibility in the form of the WS standards
  • Built-in error handling
  • Automation when used with certain language products

Where to use REST

areas where REST works well for are:

  • Limited bandwidth and resources: remember the return structure is really in any format (developer defined). Plus, any browser can be used because the REST approach uses the standard GET, PUT, POST, and DELETE verbs. Again, remember that REST can also use the XMLHttpRequest object that most modern browsers support today, which adds a bonus of AJAX.
  • stateless operations: if an operation needs to be continued, then REST is not the best approach and SOAP may fit it better. However, if you need stateless CRUD (Create, Read, Update, and Delete) operations, then REST is it.
  • Caching situations: if the information can be cached because of the stateless operation of the REST approach, this is perfect.

Where to use SOAP

areas where SOAP works as a great solution:

  • Asynchronous processing and invocation: if your application needs a guaranteed level of reliability and security then SOAP 1.2 offers additional standards to ensure this type of operation. Things like WSRM – WS-Reliable Messaging.
  • Formal contracts: if both sides (provider and consumer) have to agree on the exchange format then SOAP 1.2 gives the rigid specifications for this type of interaction.
  • Stateful operations: if the application needs contextual information and conversational state management then SOAP 1.2 has the additional specification in the WS structure to support those things (Security, Transactions, Coordination, etc.). Comparatively, the REST approach would make the developers build this custom plumbing.