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.
