-
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
Keys all over, but not the names that actually work as key #136
Comments
I'll include the vocab names in that endpoint and review the others. There are some endpoints that still need the keys such as the ones to deprecate vocabs or to specify the parent of a concept. I can use names in all of them, it's just a hassle because for the concepts it requires an extra join in the DB queries. Anyway, you can also find a vocabulary by its key https://api.gbif-uat.org/v1/vocabularies?key=77 Also, not sure about removing the keys from the responses, I don't think they do any harm as long as we make clear how to use the API and it can help us find concepts in the DB (concept names are unique only within a vocabulary and they are linked to the vocabulary by its key, not its name). |
Deployed to production the I'll review the other endpoints at a later time. |
Would the solution you propose @marcos-lg make it possible to query on names and keys for all levels or only names? |
The issue is about returning the names in the responses (and not only the keys). But you can search by either key or name, e.g.: https://api.gbif-uat.org/v1/vocabularies?key=77 |
https://api.gbif-uat.org/v1/vocabularies/PreservationType/concepts/StorageFrozenMinus20?includeParents=true
That response has a lot of keys, but keys cannot be used for anything (there is no vocab 77)
example:
vocabularyKey: 77
But there isn't really anyway for me to know what vocabulary I'm looking at except from trying to do a regex on other fields like
"alternativeLabelsLink": "https://api.gbif-uat.org/v1/vocabularies/PreservationType/concepts/StorageFrozenMinus20/alternativeLabels",
Are they in the API response for a reason or is it internal values that gets leaked to the API? If they cannot be used for anything, then I think we should remove them. They are just a cause of confusion then.
And secondly: could we instead include names when then they aren't there. Such as the vocabulary name in above example
The text was updated successfully, but these errors were encountered: