Evolution of the supervisor's HTTP API

Greetings and salutations!

We’ve been working recently on cleaning up the supervisor’s HTTP API, first by formalizing the API with a JSON schema and most recently by performing some optimizations to clean up state files on disk.

What we’d like to clean up next is the actual output that the HTTP API returns, both by removing fields that are useless, and streamlining existing fields that might not be as easy to consume as they should be.

That brings me to the crux of this post. I’m interested to get opinions from anyone that’s used the supervisor’s HTTP API. Things like:

  • what information do you want to see that’s not currently there?
  • what bothers you about the API as it stands today?

Honestly any thoughts on the HTTP API at all are welcome. Don’t feel constrained by my list. Feel free to respond to this post with your thoughts, or comment on the GitHub issue that will track this work.

Thank you!

I’d love to see some routes or url arguments to provide human-readable versions of API responses, since the HTTP API is the only mechanism we have right now for examining ring status.

1 Like