@anna-parker and I just realized we'd independently been bothered by our swagger UI grouping being not very logical for API consumers, the current grouping is based on code organization, which is nothing API users should have to think about.
Certain backend APIs are written for public consumption (e.g. submission) while others are not really intended to be for public consumption (e.g. get original metadata). We should group things into stable and unstable APIs (private coming with no stability guarantees, if API users want them to become stable they should contact us).
@anna-parker and I just realized we'd independently been bothered by our swagger UI grouping being not very logical for API consumers, the current grouping is based on code organization, which is nothing API users should have to think about.
Certain backend APIs are written for public consumption (e.g. submission) while others are not really intended to be for public consumption (e.g. get original metadata). We should group things into stable and unstable APIs (private coming with no stability guarantees, if API users want them to become stable they should contact us).
Tasks: