-
Notifications
You must be signed in to change notification settings - Fork 11
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
Can we have two endpoints providing complelely different data using the same infores? #93
Comments
We previously decided that this would be ok. See: https://github.com/NCATSTranslator/TranslatorArchitecture/blob/master/SmartAPIRegistration.md#server-count We could always revisit this decision, but currently it is explicitly allowed. |
To be clear though, there should only be 1 smartapi registration, it is allowed to have two servers in the server block for one environment. |
@cbizon I don't think these answer my question, but I suppose my question wasn't very clear. I have changed the title. The question really is: Can there be two endpoints with different SmartAPI registrations providing completely different data using the same infores? The URL that you quote above says this:
Notably, "they must provide equivalent responses". The endpoints from my question provide completely different responses. |
Gotcha. That's right. These look like different services, and should therefore have different infores identifiers. Maybe the first should be "infores:gelinea" or similar. |
@vdancik ? |
I did change the SmartAPI registration when I was alerted the issue, but I think that as a matter of policy it makes sense to allow multiple SmartAPI registrations per infores. |
@vdancik How so? It seems to lead to confusion... |
Short answer to this issue: no. Infores usage in the SmartAPI Registry should be globally unique as to the cross-product of infores and TRAPI version (however, the Biolink Model release version is not constraining here, I believe... @sierra-moxon?) |
I agree that infores id's should be globally unique. I'll add that having two identical infores id's in the infores catalog, with each pointing to distinct services will present a major headache for the UI team, as they rely heavily on the infores catalog for finding resources and associated information (e.g., wiki URLs). |
If the data is completely different, we need a new infores identifier. The version of the resource is not included in the definition of unique for infores identifiers. |
Just weighing in to agree with where i think things ended up here. If the data/knowledge hosted by two endpoints/services is different, they should have different infores ids. However, infores ids are not version-specific - e.g. a single 'molepro' infores even if molepro v2 has some new/different content than molepro v1. I also think it is fine to stand up >1 endpoint for a given infores (e.g. http vs https, or v1 vs v2), as long as they generally serve the same information. |
ARAX code had made the assumption that there would not be two endpoints (at the same TRAPI version) hosting different data advertising the same infores key. When this happened, ARAX ended up dropping one:
Should it be permitted to have two different endpoints providing different information (and thus both be considered), both advertising the same infores key?
This may have downstream use implications.
The text was updated successfully, but these errors were encountered: