Skip to content
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

Closed
georgschermann opened this issue Nov 23, 2016 · 2 comments
Closed

splitting the manifest #11

georgschermann opened this issue Nov 23, 2016 · 2 comments

Comments

@georgschermann
Copy link

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?

@wrygiel
Copy link
Contributor

wrygiel commented Dec 2, 2016

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.

@wrygiel wrygiel closed this as completed Dec 2, 2016
@wrygiel
Copy link
Contributor

wrygiel commented Dec 2, 2016

For example, one of your current manifests is served at:

https://www.service4mobility.com/europe_dev/ewp/manifest?api=echo

But its own self-reference points to a different URL:

https://www.service4mobility.com/europe_dev/ewp/manifest

So the Registry Service warns you about it:

https://dev-registry.erasmuswithoutpaper.eu/status?url=https://www.service4mobility.com/europe_dev/ewp/manifest?api=echo

We have found an inconsistency in your Discovery API manifest. We were expecting to find this URL in one of your discovery/url elements, but we didn't:
https://www.service4mobility.com/europe_dev/ewp/manifest?api=echo
This is not vital for most EWP clients, because Discovery API is usually accessed by the Registry Service only, but still, it seems to be a small bug that you should fix.

You should change your discovery/url to https://www.service4mobility.com/europe_dev/ewp/manifest?api=echo and the warning will disappear.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants