Responsive table Example showing Comparison between SOAP and REST services

soap_rest_comparison.html

<table border="1"><colgroup><col><col><col></colgroup><thead><tr class="header"><th><p class="SimplePara">Topic</p></th><th><p class="SimplePara">SOAP</p></th><th><p class="SimplePara">REST</p></th></tr></thead><tbody><tr class="noclass"><td><p class="SimplePara">Origin</p></td><td><p class="SimplePara">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
                    .</p></td><td><p class="SimplePara">REST (Representational State Transfer) was created in 2000 by Roy Fielding at UC, Irvine. Developed in an academic environment, this protocol embraces the philosophy of the open Web.</p></td></tr><tr class="noclass"><td><p class="SimplePara">Basic Concept</p></td><td><p class="SimplePara">Makes data available as services (verb + noun), for example “getUser” or “PayInvoice”</p></td><td><p class="SimplePara">Makes data available as resources (nouns), for example “user” or “invoice”</p></td></tr><tr class="noclass"><td><p class="SimplePara">Pros</p></td><td><p class="SimplePara">Follows a formal enterprise approach</p><p class="SimplePara">Works on top of any communication protocol, even asynchronously</p><p class="SimplePara">Information about objects is communicated to clients.</p><p class="SimplePara">Security and authorization are part of the protocol.</p><p class="SimplePara">Can be fully described using WSDL</p></td><td><p class="SimplePara">Follows the philosophy of the Open Web</p><p class="SimplePara">Relatively easy to implement and maintain</p><p class="SimplePara">Clearly separates client and server implementations</p><p class="SimplePara">Communication isn’t controlled by a single entity</p><p class="SimplePara">Information can be stored by the client to prevent multiple calls.</p><p class="SimplePara">Can return data in multiple formats (JSON, XML etc.)</p></td></tr><tr class="noclass"><td><p class="SimplePara">
                        Cons
                      
                    
                      </p></td><td><p class="SimplePara">Spends a lot of bandwidth communicating metadata</p><p class="SimplePara">Hard to implement and is unpopular among Web
                     and mobile developers</p></td><td><p class="SimplePara">Only works on top of the HTTP protocol</p><p class="SimplePara">Hard to enforce authorization and security on top of it</p></td></tr><tr class="noclass"><td><p class="SimplePara">When to use</p></td><td><p class="SimplePara">When clients need to have access to objects available on servers</p><p class="SimplePara">When you want to enforce a formal contract between client and server</p></td><td><p class="SimplePara">When clients and servers operate on a Web environment</p><p class="SimplePara">When information about objects doesn’t need to be communicated to the client</p></td></tr><tr class="noclass"><td><p class="SimplePara">When not to use</p></td><td><p class="SimplePara">When you want the majority of developers to easily use your API</p><p class="SimplePara">When your bandwidth is very limited</p></td><td><p class="SimplePara">When you need to enforce a strict contract between client and server</p><p class="SimplePara">When performing transactions that involve multiple calls</p></td></tr><tr class="noclass"><td><p class="SimplePara">Use cases</p></td><td><p class="SimplePara">Financial services</p><p class="SimplePara">Payment gateways</p><p class="SimplePara">Telecommunication services</p></td><td><p class="SimplePara">Social media services</p><p class="SimplePara">Social networks</p><p class="SimplePara">Web chat services</p><p class="SimplePara">Mobile services</p></td></tr><tr class="noclass"><td><p class="SimplePara">Examples</p></td><td><p class="SimplePara">
                    <span class="ExternalRef"><a href="https://www.salesforce.com/developer/docs/api/"><span class="RefSource">
                            <span class="EmphasisFontCategoryNonProportional">https://www.salesforce.com/developer/docs/api/</span>
                          </span></a></span> - Salesforce SOAP
                     API</p><p class="SimplePara">
                    <span class="ExternalRef"><a href="https://developer.paypal.com/docs/classic/api/PayPalSOAPAPIArchitecture/"><span class="RefSource">
                            <span class="EmphasisFontCategoryNonProportional">https://developer.paypal.com/docs/classic/api/PayPalSOAPAPIArchitecture/</span>
                          </span></a></span> -Paypal SOAP API</p></td><td><p class="SimplePara">
                        <span class="ExternalRef"><a href="https://dev.twitter.com/"><span class="RefSource">
                            <span class="EmphasisFontCategoryNonProportional">https://dev.twitter.com/</span>
                          </span></a></span>
                      </p><p class="SimplePara">
                        <span class="ExternalRef"><a href="https://developer.linkedin.com/apis"><span class="RefSource">
                            <span class="EmphasisFontCategoryNonProportional">https://developer.linkedin.com/apis</span>
                          </span></a></span>
                      </p></td></tr><tr class="noclass"><td><p class="SimplePara">Conclusion</p></td><td><p class="SimplePara">Use SOAP
                      
                     if you are dealing with transactional operations and you already have an audience that is satisfied with this technology.</p></td><td><p class="SimplePara">Use REST if you’re focused on wide-scale API adoption or if your API is targeted at mobile apps.</p></td></tr></tbody></table>

The Content has been taken from Pro Rest API, By Sanjay Patni