-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
splitting the manifest #11
Comments
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.
Every online manifest file instance is in fact a Discovery API implementation. Therefore, you should have a single 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.
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. |
For example, one of your current manifests is served at:
But its own self-reference points to a different URL:
So the Registry Service warns you about it:
You should change your |
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?
The text was updated successfully, but these errors were encountered: