REST vs SOAP: Nordic APIs Infographic comparison Rhys Fisher January 20, 2015 Soap vs. Rest A NordicAPIs infographic 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. 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. Basic Concept REST Makes data available as resources (nouns), for example “user” or “invoice”” SOAP 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) 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 SOAP Spends a lot of bandwidth communicating metadata Hard to implement and is unpopular among Web and mobile developers Uses only XML When to use REST When clients and servers operate on a Web environment When information about objects doesn’t need to be communicated to the client SOAP When clients need to have access to objects available on servers When you want to enforce a formal contract between client and server When not to use REST When you need to enforce a strict contract between client and server When performing transactions that involve multiple calls SOAP When you want the majority of developers to easily use your API When your bandwidth is very limited Common use cases REST Social Media services Social Networks Web Chat services Mobile Services SOAP Financial services Payment gateways Telecommunication services Popular examples REST Twitter API LinkedIn API Slack API SOAP Salesforce SOAP API Paypal SOAP API Clickatell SMS SOAP API Conclusion 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 [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”]
