REST vs SOAP: Nordic APIs Infographic comparison

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.


origin 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 (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



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



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


pros 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


  • 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 REST


  • only works on top of the HTTP protocol
  • Hard to enforce authorization and security on top of it
cons 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



  • When clients and servers operate on a Web environment
  • 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 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


  • When you need to enforce a strict contract between client and server
  • When performing transactions that involve multiple calls
when not to use 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


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


  • Financial services
  • Payment gateways
  • Telecommunication services

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.

[easy-social-share buttons=”facebook,twitter,google,linkedin,mail,reddit,hackernews” template=”flat-retina” counters=0 style=”icon_hover” sidebar=”yes” sidebar_pos=”right” ]
[easy-social-share counters=0 fullwidth=”yes” template=”flat-retina”]