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

Client uses non-standard server URL #40

Open
uniqueg opened this issue Jan 27, 2023 · 3 comments · Fixed by #46
Open

Client uses non-standard server URL #40

uniqueg opened this issue Jan 27, 2023 · 3 comments · Fixed by #46
Assignees
Milestone

Comments

@uniqueg
Copy link
Collaborator

uniqueg commented Jan 27, 2023

According to TES v1.0 and v1.1, the TES API should be hosted at /ga4gh/tes/v1:

servers:
- url: /ga4gh/tes/v1 

Currently, py-tes adds just /v1 as a suffix to the TES URL, and before the API paths /tasks and /service-info (compare #39).

In my opinion, py-tes should add /ga4gh/tes/v1 by default. But for greater (and backwards) compatibility, the TES URL suffix should perhaps be configurable.

@uniqueg
Copy link
Collaborator Author

uniqueg commented Feb 9, 2023

@kellrott:

I see three main options to address this:

  • Have the py-tes consumer specify the full path to the API when registering the client, that is, e.g., https://http://funnel.example.com/ga4gh/tes/v1 (for proTES) or http://funnel.example.com/v1 (for TESK and Funnel). It's the most flexible, because it allows any prefix in principle.
  • Use f"{url}/ga4gh/tes/v1" to put pressure on implementations to be spec-compliant. But this is perhaps not so helpful, if at least two of the three major implementations are currently not following the spec here and couldn't possibly be accessed with py-tes if the /ga4gh/tes/v1 part is hardcoded in the access methods.
  • py-tes could try the different options successively (in case of 404, try next):
    1. Assume API at f"{url}/ga4gh/tes/v1"
    2. Assume API at `f"{url}"
    3. Assume API at f"{url}/v1"
      This would be the most flexible, as it would allow the APIs to be deployed at any route, while still supporting standards-compliant and legacy implementations. But maybe you think that this should not be the job of py-tes, but rather an upstream client like a TES gateway?

Please let me know what you think.

@kellrott
Copy link
Contributor

kellrott commented Feb 9, 2023

I'm kind of in favor of doing some amount of automatic work for the user. For a true lightweight implementation, someone could use https://pypi.org/project/pydantic-tes/ So maybe py-tes should offer a little bit more 'easy of use' for softening issues between implementations

@kellrott kellrott added this to the 0.5.0 milestone Feb 10, 2023
@uniqueg
Copy link
Collaborator Author

uniqueg commented Feb 10, 2023

Got it! Will go with the last option then. It's also my favorite. And I guess that would also answer the question in #39.

Might be good to add this as an issue to Funnel. I have also created one in TESK: elixir-cloud-aai/tesk-api#48

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

Successfully merging a pull request may close this issue.

2 participants