REST vs SOAP: Nordic APIs Infographic comparison Rhys Fisher January 20, 2015 Soap vs. RestA NordicAPIs infographicHas 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.OriginRESTREST (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.SOAPSOAP (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.Basic ConceptRESTMakes data available as resources (nouns), for example “user” or “invoice””SOAPMakes data available as services (verb + noun), for example “getUser” or “PayInvoice”ProsRESTFollows the philosophy of the Open WebRelatively easy to implement and maintainClearly separates client and server implementationsCommunication isn’t controlled by a single entityInformation can be stored by the client to prevent multiple callsCan return data in multiple formats (JSON, XML etc)SOAPFollows a formal enterprise approachWorks on top of any communication protocol, even asynchronouslyInformation about objects is communicated to clientsSecurity and authorization are part of the protocolCan be fully described using WSDLConsRESTonly works on top of the HTTP protocolHard to enforce authorization and security on top of itSOAPSpends a lot of bandwidth communicating metadataHard to implement and is unpopular among Web and mobile developersUses only XMLWhen to useRESTWhen clients and servers operate on a Web environmentWhen information about objects doesn’t need to be communicated to the clientSOAPWhen clients need to have access to objects available on serversWhen you want to enforce a formal contract between client and serverWhen not to useRESTWhen you need to enforce a strict contract between client and serverWhen performing transactions that involve multiple callsSOAPWhen you want the majority of developers to easily use your APIWhen your bandwidth is very limitedCommon use casesRESTSocial Media servicesSocial NetworksWeb Chat servicesMobile ServicesSOAPFinancial servicesPayment gatewaysTelecommunication servicesPopular examplesRESTTwitter APILinkedIn APISlack APISOAPSalesforce SOAP APIPaypal SOAP APIClickatell SMS SOAP APIConclusionThe 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[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”] This post is older than 4 years. External links has been removed
