tl;dr: microservice authoring information at https://sqr-015.lsst.io
As the number of services DM provides grows, it’s going to be harder and harder to maintain knowledge of them all, and hard to enforce a consistent interface.
SQuaRE is proposing using api.lsst.codes as a service-brokering front end that will provide discoverability and interface consistency for services hosted there. Effectively, this is insertion of a microservice layer between the back-end service (e.g. status.lsst.codes, squash.lsst.codes) and a machine consumer of the service data.
Our first consumer is the sqrbot chatbot. You may have seen it in action on #dm-square-status on the LSSTC Slack, providing monitor and query services.
(Our plan for chatops is that the chatbot is simply a presentation layer and conversation manager: fundamentally, it queries an API, gets back JSON, and then chooses how to present it, but does not implement service logic itself. The “conversation manager” part simply means that we intend to hook a memory up to the chatbot such that you can interactively, say, define a technote by answering a series of questions. That bit isn’t there yet.)
Anyway, to make development of api.lsst.codes-compliant microservices easier, we’ve defined a set of metadata that we expect services hosted by api.lsst.codes to provide to their consumers. That metadata definition is coupled to a Python module which provides a framework for a Flask app that bakes metadata routes into the microservice you’re writing. Not only that, but we’ve got a cookiecutter template to stamp out a microservice such that most of what you have to do is implement your service transformation logic and write the README–the rest is handled for you.
And best of all, it’s all documented in https://sqr-015.lsst.io .