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

Can we have two endpoints providing complelely different data using the same infores? #93

Open
edeutsch opened this issue Sep 29, 2023 · 11 comments

Comments

@edeutsch
Copy link
Collaborator

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:

image

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.

@cbizon
Copy link
Collaborator

cbizon commented Sep 30, 2023

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.

@cbizon
Copy link
Collaborator

cbizon commented Sep 30, 2023

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.

@edeutsch edeutsch changed the title Can we have more than one endpoint for one infores? Can we have two endpoints providing complelely different data using the same infores? Oct 2, 2023
@edeutsch
Copy link
Collaborator Author

edeutsch commented Oct 2, 2023

@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:

There must exist at least one server per (infores, x-maturity). It is allowed to register two or more server urls for a given (infores, x-maturity), for instance to provide both http and https interfaces. The caller to these services may use either and they must provide equivalent responses.

Notably, "they must provide equivalent responses".

The endpoints from my question provide completely different responses.

@cbizon
Copy link
Collaborator

cbizon commented Oct 2, 2023

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.

@cbizon
Copy link
Collaborator

cbizon commented Oct 2, 2023

@vdancik ?

@vdancik
Copy link
Collaborator

vdancik commented Oct 3, 2023

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.

@gglusman
Copy link

gglusman commented Oct 3, 2023

@vdancik How so? It seems to lead to confusion...

@RichardBruskiewich
Copy link

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?)

@karafecho
Copy link

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).

@sierra-moxon
Copy link
Member

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.

@mbrush
Copy link

mbrush commented Oct 9, 2023

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.

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

8 participants