Soap vs. Rest

A NordicAPIs infographic

rest vs soap

Has your boss made you responsible for your company's first API? Wondering which protocol you should use?

In this post, we’ll take a fresh look at the REST vs SOAP comparison.

We’ve created an infographic that will show you which protocol is a better fit. We’ve looked at the REST vs SOAP from a use-case perspective, hopefully making it easier to choose which protocol is better suited for your job.

originOrigin

origin REST

REST

REST (Representational State Transfer) was Created in 2000 by Roy Fielding in UC, Irvine. Developed in an academic environment, this protocol embraces the philosophy of the open Web.

origin SOAP

SOAP

SOAP (Simple Object Access Protocol), was created in 1998 by Dave Winer et al in collaboration with Microsoft. Developed by a large software company, this protocol addresses the goal of addressing the needs of the enterprise market.

concept_titleBasic Concept

concept1

REST

Makes data available as resources (nouns), for example “user” or “invoice””

concept2

SOAP

Makes data available as services (verb + noun), for example “getUser” or “PayInvoice”

concept_titlePros

pros REST

REST

  • Follows the philosophy of the Open Web
  • Relatively easy to implement and maintain
  • Clearly separates client and server implementations
  • Communication isn’t controlled by a single entity
  • Information can be stored by the client to prevent multiple calls
  • Can return data in multiple formats (JSON, XML etc)
pros SOAP

SOAP

  • Follows a formal enterprise approach
  • Works on top of any communication protocol, even asynchronously
  • Information about objects is communicated to clients
  • Security and authorization are part of the protocol
  • Can be fully described using WSDL

cons_titleCons

cons REST

REST

  • only works on top of the HTTP protocol
  • Hard to enforce authorization and security on top of it
cons SOAP

SOAP

  • Spends a lot of bandwidth communicating metadata
  • Hard to implement and is unpopular among Web and mobile developers
  • Uses only XML

cons_titleWhen to use

concept1

REST

  • When clients and servers operate on a Web environment
  • When information about objects doesn’t need to be communicated to the client
concept1

SOAP

  • When clients need to have access to objects available on servers
  • When you want to enforce a formal contract between client and server

SOAP vs REST when not to useWhen not to use

when not to use REST

REST

  • When you need to enforce a strict contract between client and server
  • When performing transactions that involve multiple calls
when not to use SOAP

SOAP

  • When you want the majority of developers to easily use your API
  • When your bandwidth is very limited

REST vs SOAP use casesCommon use cases

REST use cases

REST

  • Social Media services
  • Social Networks
  • Web Chat services
  • Mobile Services
SOAP use cases

SOAP

  • Financial services
  • Payment gateways
  • Telecommunication services

SOAP vs REST examplesPopular examples

REST examples

REST

SOAP examples

SOAP

REST vs SOAP infographic conclusionConclusion

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.

View/ Download as an image
  • mannetroll
    • travisspencer

      We talked a lot about that as we produced this graphic. In the end, we decided, for better or worse, to go with the flow of lumping real REST services together with all other HTTP-based Web APIs. Part of the reason being that not-exactly-RESTful services can mature into truly RESTful ones: https://twitter.com/nordicapis/status/442934904759025664

      Perhaps we’ll do a REST vs. not-quite-RESTful APIs infographic next ;-)

  • terracerulean

    Not too shabby. I will be sharing this. I would like to see two additional sections: Similarities and Differences.

  • Good resource. Personally I think calling it an infographic didn’t do it justice. I almost didn’t click in, as I have very little respect for the infographic format, but this was simple, informative, and well presented. Nice work.

  • I should point out Paypal has REST APIs going forward, our SOAP support is considered legacy (https://developer.paypal.com/docs/api/). Also, contracts can be enforced with REST using Swagger/RAML/Apiary/etc+JSON Schema, albeit somewhat different.

  • Ioseb Dzmanashvili

    Well, i expressed myself quite rudely on Twitter and was suggested by @nordicapis to give some specific points. Here are my points(from bottom to up):

    Popular examples (REST):
    – Twitter API is not RESTful. It screams RPC, it violates not only REST constraints, but abuses HTTP protocol as well.
    – LinkedIn API is a good example of Web API, though is far from being RESTful
    – Slack API is an example of RPC API and this fact is mentioned in their documentation.

    Common use cases (REST):
    – REST is not restricted to these kind of services, it is misleading.

    When not to use (REST):
    – “When you need to enforce a strict contract between client and server” <- this is wrong. Contracts in REST are defined at least of Media Type(s) and underlying Application Protocol. The contract can be as strict as needed. Aforementioned statement completely misses the meaning of contract in REST APIs and is misleading.
    – "When performing transactions that involve multiple calls" <- not true. Being stateless does not mean that one can not do transactions that involve multiple "calls". It can be coordinated though resource representations and this statement is false.

    When not use use (SOAP):
    – "When you want the majority of developers to easily use your API" <- this is not argument agains SOAP. "Easiness" is a relative term.
    – "When your bandwidth is very limited" <- this can be valid for REST APIs too.

    When to use (REST):
    – "When clients and servers operate on a Web environment" is not true. REST Architectural Style is not bound to particular protocols or Web infrastructure. It is 100% possible and achievable to build perfectly RESTful services out of the Web platform.
    – "When information about objects doesn’t need to be communicated to the client" <- Wrong. Information about "objects" should be communicated and it is either communicated directly through Media Type specification, micro formats or profiles.

    When to use (SOAP):
    – "When clients need to have access to objects available on servers" <- this is not exclusive to SOAP. The fact that in REST one shouldn't expose Domain Model Objects, doesn't mean that it is impossible to expose necessary information properly. This "access to objects available on servers" doesn't mean anything in this particular case.
    – "When you want to enforce a formal contract between client and server" <- Again, contract is an important thing in REST it is maintained differently though. And anyone who thinks that contract is not important in REST, is wrong.

    Cons (REST):
    – "only works on top of the HTTP protocol" there is no such restriction. REST requires proper binding to underlying communication protocols and adherence to REST constraints. HTTP is not requirement.
    – "Hard to enforce authorization and security on top of it" <- how come? is it easy in SOAP?

    Cons (SOAP):
    – "Spends a lot of bandwidth communicating metadata" <- the fact that it is possible to designed RESTful services that spend less bandwidth, doesn't mean that REST services definitely consume less resources. It depends on particular service goal and design.
    – "Hard to implement and is unpopular among Web and mobile developers" <- Can someone show me properly implemented popular REST service? I do not say that there are no properly implemented REST services, though popularity among Web and mobile developers is solely defined by availability of web infrastructure and tools(curl, XHR etc…) and this kind of popularity is not related(in majority of cases) to REST at all.

    Pros (REST):
    – "Follows the philosophy of the Open Web" <- not a requirement.
    – "Relatively easy to implement and maintain" <- oh really? on which side? give me good client success stories that have success of this "easyness". On server side of things it is relatively easy, though it can be complete nightmare to properly implement clients. Reason? it requires a lot of expertise for developers and lack of tools.
    – "Clearly separates client and server implementations" <- no one said that it is impossible in SOAP, just who cares? these are words for words…

    Pros (SOAP):
    – "Works on top of any communication protocol, even asynchronously" <- i wanna see good example over UDP. REST is not tide to any communication or application protocol as well.
    – "Information about objects is communicated to clients" <- who said that there is no need to communicate information about "objects" in REST?
    – "Security and authorization are part of the protocol" <- i want to see good example of mmm… integration of PHP client and .Net Server when service uses SOAPs security features… good luck with that.
    – "Can be fully described using WSDL" <- this statement implies that WSDL is an advantage per se and lack of something like this in REST is disadvantage.

    • Hi Ioseb,

      Thanks for the great feedback. Let me try to reply to some of your comments:

      1. “Contracts in REST are defined at least of Media Type(s) and underlying Application Protocol. The contract can be as strict as needed.” – If you’re talking about JSON Schema then this is wrong because “JSON Schema limits itself to describing the structure of JSON data, it cannot express functional constraints.”, in http://json-schema.org/example2.html

      2. “Being stateless does not mean that one can not do transactions that involve multiple ‘calls’. It can be coordinated through resource representations and this statement is false.” – This is wrong because to be able to perform a transaction there needs to be coordination between client and server and “each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server.”, in “Architectural Styles and the Design of Network-based Software Architectures”, Roy Thomas Fielding, §5.3.1

      3. “Information about ‘objects’ should be communicated and it is either communicated directly through Media Type specification, micro formats or profiles.” – This is wrong because the information being communicated is about resources, not objects, and “a resource is a conceptual mapping to a set of entities, not the entity that corresponds to the mapping at any particular point in time.”

      4. “I wanna see good example over UDP.” – Please read the specification which includes a number of examples: http://docs.oasis-open.org/ws-dd/soapoverudp/1.1/os/wsdd-soapoverudp-1.1-spec-os.html

  • mikestowe

    Just for clarification, REST in itself is not limited to the HTTP protocol as it is actually protocol-less. However, because REST can be used easily over HTTP (without requiring special clients or protocols) this is the most popular implementation, and most RESTful Web APIs are confined to the HTTP protocol due to their reliance on HTTP methods (GET, POST, PUT, etc) – however, this is not a constraint of REST itself, but rather the API’s design.

    Also, on top of Jason’s comment regarding PayPal, I think it’s important to note that SalesForce provides both a REST and a SOAP API, encouraging the use of SOAP when you need to utilize a WSDL for use with previously installed (read as legacy) middleware systems – https://help.salesforce.com/HTViewHelpDoc?id=integrate_what_is_api.htm.

    Last but not least, could you expand on the authentication as RESTful APIs are fairly easy to secure using API keys and access tokens (OAuth2), or in worst case basic auth (use OAuth2 please). I think explaining what you mean about REST being harder to secure would be helpful :)

    Overall nice job, and thank you for putting this together! I have to echo Mr. Lane on saying this is very nicely done, and is definitely more than an infographic ;) Will definitely be sharing this!

  • Excellent summary, thanks for providing this.

Send this to a friend