-
Notifications
You must be signed in to change notification settings - Fork 15
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
Web API versioning #64
Comments
Will this really work? I assume there will be clashes in the library names unless the primary version appears in the name of all the related code (omero_api_v1, omero_marshal_v1, ...) If not, it sounds more like there would be the need to deploy and manage multiple web servers.
As an aside, having all of omero-api depend on all BlitzGateway seems cumbersome, which is mostly just a vote for the follow-up splitting discussion.
Can we hide changes to OMERO model behind the omero_marshal version, which brings me to the point:
If possible, I'd think pinning the api to a major marshal version would be appropriate. |
How will this appear to non-omero clients using the API? If the API version isn't in the URL is there an easy way for them to detect it? |
Seconding #64 (comment), the strategy for I would also vote for pinning the dependency of |
Agreeing with the above comments. I don't think not having the major version in the URL is a usability improvement. Personally I'd also prefer Yes, we should pin the In an ideal world, Regarding |
I think this is what
it seams to be more like others do rather then hidden in the middle of URL Maybe using prefix is not the most intuitive way, but we could just have What is exactly the use-case where someone would like to run multiple versions of API at the same time? |
I think https://github.com/openmicroscopy/openmicroscopy/blob/develop/components/tools/OmeroWeb/omeroweb/api/views.py#L64 will give you version including absolute urls |
Public data repositories such as the IDR |
@manics, sure but more specific and realistic one? |
Isn't that realistic enough? |
Just speculative but since we have already seen something similar with PathViewer and the need to support multiple server versions I don't think it's a stretch to expect that at some point a deployment may need to run two versions of the API to support clients or plugins that work exclusively with one version of the API or another. The lion share of web APIs that I have interacted with have the version number after the |
A good blog post, and further interesting set of references, in case anyone really has the patience to read up more on the topic and get an idea of some of the alternatives: |
I think my question was about concrete examples of how and where we could consider deploying multiple versions of API within single instance of OMERO.web? What is possible now and what may be possible in the future? (that is brainstorming, isn't it?) My impression is that we strictly connect versioning of API with schema, although data itself may also be versioned using the same version of software. |
Can the web-api be run on it's own (just django, no OMERO.web)? |
@manics No, /api app uses a lot of OMERO.web for login, connection, decorators etc. |
We recently discussed this issue, which is kinda complex and really needs some decisions made.
API versions
Currently we have version in api url E.g.
/api/v0.1/m/projects/
but this is only useful if we're supporting more than 1 version at a time.So, do we want to do that, and if so, how?
When we last discussed this, I think the consensus was moving towards "Only support 1 version at a time".
This will really simplify our lives (and be much less confusing for users).
If users really need access to multiple versions at a time, they can choose to deploy 2 separate versions of the app, under different url prefixes of their choosing.
Any objections to this approach?
OMERO_marshal versions
Currently, the web API will be affected by:
omero_marshal
Do we specify a fixed version of omero_marshal for each release of the OMERO? Currently this is fixed at
0.4.1
in requirements-common.txtOr do we allow users to install latest omero_marshal and say in our API docs that the json you get will depend on your omero_marshal version?
Decoupling
If we decouple OMERO, OMERO.web, BlitzGateway, api app etc, then these questions get amplified by many factors! Since we are currently moving more of the web api logic into BlitzGateway, these are becoming less decoupled. I don't see us resolving these issues in time for 5.3.0 since the priority has to be on building the api itself.
cc @chris-allan @joshmoore @aleksandra-tarkowska @jburel @emilroz
The text was updated successfully, but these errors were encountered: