Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


 
 

REST vs. SOAP - SOAP's Revenge

Posted by Gigi Sayfan on Nov 30, 2015

The year was 1999, the internet was blooming, Simple Object Access Protocol (SOAP) burst onto the scene, based on the latest and greatest dev: XML. SOAP had its 15 minutes of fame, but was very verbose and prescriptive and often required tooling to use it efficiently. A whole family of web service specifications (WS-*) grew on top of SOAP and it was used successfully for interoperability.

The relatively heavy weight of the SOAP protocol didn't sit well with the nimble web developers of the time. Representational State Transfer (REST) was just the thing - simple to describe, very flexible and almost directly mapped to HTTP. No need for special libraries to consume.

Fast forward to 2015 and you see a plethora of REST best practices, how to validate your content (JSON schema), how to authenticate, how to report errors, how to implement stateful interactions, etc. Everyone and their cousin has their own flavor. What do you put in the HTTP headers, what do you send as URL parameters and what is in the request body? HATEOAS or not HATEOAS?



These days, every Enterprise/best practice REST API is a proprietary and non-standard half implementation of SOAP. The SOAPjr project attempts to combine the simple parts of SOAP with JSON-RPC to create a clean and yet structured web API protocol. It will be interesting to see how future web APIs are going to be implemented.

TAGS:

REST, SOAP, SOAP API, REST API


Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap
Thanks for your registration, follow us on our social networks to keep up-to-date