Often we don’t have a choice over the systems we integrate with. Not everything can be a simple, self-documented, “RESTful” API.
Consider a SOAP API that requires a standard but uncommonly used feature. The average library in your programming language of choice may not support every SOAP feature under the sun. Even Leapfrog’s own SOAP library for Python is far from feature-complete.
Now consider a diverse stack made up of multiple distinct systems, written in multiple programming languages, for both consumer-facing and internal business procedures.
The promise of SOA through SOAP solutions becomes less and less appealing. At Leapfrog, we’ve found adopting JSON as a lightweight alternative to SOAP in a SOA-inspired platform meets the best of all worlds.
So what about all your vendors that use SOAP?
Fear not! There’s a recipe to solve all your problems:
RESTfulAPIs have become commonplace in the world of the web.
Given that “REST” itself is a concept and not a protocol, RESTful APIs must only obey a minimal set of rules that can be abused by developers in any way they like.
While the transport protocol might often be HTTP, the rules for interacting with the API (i.e., the API’s protocol) are largely defined by the API itself. I almost want to label these as “simple HTTP services”, because many APIs that label themselves as “RESTful” really aren’t. Consider a JSON-over-HTTP API that happens to maintain state. It’s not RESTful, but it uses elements commonly found in RESTful APIs.
The simple HTTP service has gained popularity for a few reasons. It uses the same transport protocol as traditional webpages, and if it’s a RESTful service, it’s modeled on how the web works: stateless and resource-oriented. An HTTP service that uses JSON as the payload format enables quick and easy interoperability with a web browser—and nearly every modern...