If that sounds vaguely like UDDI (which dealt with discovery and search of WSDL then you’re on the right track.
Glue is this week, and preceding the conference was the 2015 API Strategy and Practice Tech Un-Workshops. One of the lightning talks (and they were lightning fast, let me tell you) was all about APIs.JSON – a relatively new collaborative effort between Kin Lane, API Evangelist, and Steven Willmott and Nicolas Grenie of 3scale networks,
The effort – which you can dig into at apisjson.org – is an attempt to provide a more formal and standardized definition of APIs designed for “public deployment and consumption by automated software agents (robots)”. In a nutshell, automated agents (and people, too, if you like reading machine-consumable metadata) can access a meta description of the APIs available for an organization at a known (standardized) URI such as http://company.com/apis.json.
It’s not quite a WSDL for JSON, as the metadata is not describing the actual interfaces, but more like UDDI entry that might have once (and maybe still is) hosted in a registry (repository). The current incarnation provides basic information about the APIs and includes basic properties like a name and descriptions and URLs and can also contain more (some might say usable) information such as links to documentation or an actual, real-life readable API definition such as Swagger or API Blueprint formats as well as WADL and WSDL.
The effort is showcased in an open API search engine (http://apis.io) that allows individuals to seek out APIs (over 900 are listed today) based on a variety of criteria, all of which of course is derived from the metadata within an APIs.JSON file.
What does this all have to do with DevOps? Well, as Steve Willmott astutely pointed out in his lightning talk, APIs.JSON is not just about describing APIs in a consumable format, but it’s about being able to have machines discover and bootstrap APIs. That means potentially being able to trigger and signal changes about an API to kickstart a new build and deployment process.
This is a great example of the possibilities for collaboration between Dev and Ops when everything is treated like code and automation moves from simple tasks to workflows – to orchestration.
And I probably don’t have to mention (but I will, because , me) that the same trigger and signaling process could (and probably will) hook into broader network infrastructure (the components that exhibit high application affinity like load balancing and caching and app security) to drive more automated change management.
APIs.JSON is not the first (and won’t be the last) effort of this kind because the mobile and app economy of the future is being built on APIs and thus , as Steve Willmott stated in his talk, “the Web of APIs is the future of the web.”