wrygiel
commented
7 years ago our current approach is to split the manifest per API which results in one manifest file per API which contains all covered HEIs for this API.
Keep in mind, that if you have two HEIs which implement different versions of a single API, then you'll need to split them too.
The question came up, if the "apis-implemented -> discovery" element should be somewhere in these manifest files or not.
Every online manifest file instance is in fact a Discovery API implementation. Therefore, you should have a single <discovery> entry in each manifest file, its URL pointing to the manifest's URL. Not having it is not a critical error, but you should have it nonetheless, for completeness.
As to the multiple manifests - in the future, we will try to make it easier (e.g. allow you to serve all this information in a single manifest). But that's currently postponed after other APIs are designed.
Is it intended to have ~10 manifest files covering the discovery API for a given HEI?
There's nothing wrong with this approach, you can have as many as you need. However, I suspect that most partners will split it by HEI (not by API, as you do). E.g. in Poland, we will have a single manifest file per HEI, and I think Sweden plans to do it similarly.
Since we have dynamic API coverage per HEI we need to split up our manifest. our current approach is to split the manifest per API which results in one manifest file per API which contains all covered HEIs for this API.
The question came up, if the "apis-implemented -> discovery" element should be somewhere in these manifest files or not.
Is it intended to have ~10 manifest files covering the discovery API for a given HEI? So one would see ~10 endpoints serving the discovery API for a HEI or should it be left aside?