Add root & community info endpoints

[aspino]

Take advantage of the root endpoint, currently unused, to give some status info (version, node name, status, available communities, etc.).

Another info endpoint scoped by community (e.g: /api/learning-registry) would be useful to give community-specific details like total number of records, archive.org collection, etc.

[science]

Agree - and recommend that root endpoint no longer provide results for standard api set. So /api/envelopes wouldn't return envelopes.

Given the design purpose we're talking about, it seems like community should precede ./envelopes - and maybe it should even precede ./api? This would make mounting different communities on totally different hardware (or splitting them off later) much simpler? So propose:

• /[community]/api/envelopes (regular api for getting envelopes)
• /[community]/api (root info about community)
• /api (root info about LR node - including list of communities and ideally swagger docs)
  • Probably / should return the same as /api
• /api/envelopes (invalid!)

I'm open to putting community after the api in the path - worth thinking that through. Possibly @jimklo or @joehobson would have an opinion on this?

[aspino]

My preference is using api as the root endpoint. Keep in mind that its purpose is just to act as a top-level scope to differentiate it from other resources in the same server, like a login page, documentation or anything that involves HTML or other non-API friendly formats. This way you can be sure that anything under /api is related to the API and will return a JSON response. That's why /api/[community]/... makes more sense to me.

Agree with everything else you said.

[joehobson]

i agree with @aspino's logic of separating /api/ scope from everything else the server might be serving. Makes sense