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.

Sign up for GitHub

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

Jump to bottom

uptick the api version to 2 #1112

Closed
ctron opened this issue Dec 18, 2024 · 5 comments · Fixed by #1133
Closed

uptick the api version to 2 #1112

ctron opened this issue Dec 18, 2024 · 5 comments · Fixed by #1133
Labels
UI-V1 parity Tasks needed to get done for V1 UI parity

Comments

@ctron
Copy link
Contributor

ctron commented Dec 18, 2024

Currently the REST APIs are mounted under /api/v1. However, we consider trustify "v2". So we should mount all REST APIs under /api/v2 instead, just to be clear on that, and also to (maybe) allow compatibility APIs.

As that has a direct impact on the UI, maybe the first step would be to mount those APIs twice: once under v1 once under v2.
@ctron ctron added this to Trustify Dec 18, 2024
@ctron ctron added the UI-V1 parity Tasks needed to get done for V1 UI parity label Dec 18, 2024
@carlosthe19916
Copy link
Member

As that has a direct impact on the UI, maybe the first step would be to mount those APIs twice: once under v1 once under v2.

For the UI I don't think it is needed. The backend can switch straight to v2. The backend will generate a new openapi.yaml file and the UI can quickly catch up with it.

@jcrossley3
Copy link
Contributor

What problem does this solve? I wouldn't expect an /api/v2 endpoint to be served at a particular host:port without /api/v1 also being mounted there. To me, trustification and trustify are two completely different upstream projects with completely different API's. Conflating the two might be a downstream concern but I can't imagine anyone would want to deploy both of the upstream API's in a single downstream product, would they?

Maybe I'm not fully understanding the motivation for this?

ctron added a commit to ctron/trustify that referenced this issue Jan 13, 2025
@ctron
chore: change API version to v2
f0b048b 
BREAKING-CHANGE: This changes the prefix of the API from
/api/v1 to /api/v2 as this is the successor API of trustification (v1).

Closes: trustification#1112
@ctron ctron mentioned this issue Jan 13, 2025
Merged
@ctron
Copy link
Contributor Author

ctron commented Jan 13, 2025

What problem does this solve? I wouldn't expect an /api/v2 endpoint to be served at a particular host:port without /api/v1 also being mounted there. To me, trustification and trustify are two completely different upstream projects with completely different API's. Conflating the two might be a downstream concern but I can't imagine anyone would want to deploy both of the upstream API's in a single downstream product, would they?

Maybe I'm not fully understanding the motivation for this?

See: #1133 (comment)

@gildub
Copy link
Contributor

gildub commented Jan 13, 2025 •
edited
Loading

@carlosthe19916,

The backend can switch straight to v2.

You meant the frontend can switch to use v2 directly ?

@carlosthe19916
Copy link
Member

carlosthe19916 commented Jan 13, 2025 •
edited
Loading

@carlosthe19916,

The backend can switch straight to v2.

You meant the frontend can switch to use v2 directly ?

I meant that if the backend changes the REST paths then it will be reflected in the openapi.yaml the trustify repo has therefore triggering this action https://github.com/trustification/trustify/blob/main/.github/workflows/openapi.yaml ... and I was hoping that is all the ui repo needs to catch the changes

ctron added a commit to ctron/trustify that referenced this issue Jan 15, 2025
@ctron
chore: change API version to v2
5a9f860 
BREAKING-CHANGE: This changes the prefix of the API from
/api/v1 to /api/v2 as this is the successor API of trustification (v1).

Closes: trustification#1112
ctron added a commit to ctron/trustify that referenced this issue Jan 15, 2025
@ctron
chore: change API version to v2
ffdb750 
BREAKING-CHANGE: This changes the prefix of the API from
/api/v1 to /api/v2 as this is the successor API of trustification (v1).

Closes: trustification#1112
ctron added a commit to ctron/trustify that referenced this issue Jan 15, 2025
@ctron
chore: change API version to v2
1cb5383 
BREAKING-CHANGE: This changes the prefix of the API from
/api/v1 to /api/v2 as this is the successor API of trustification (v1).

Closes: trustification#1112
github-merge-queue bot pushed a commit that referenced this issue Jan 15, 2025
@ctron
chore: change API version to v2
e3ec2ac 
BREAKING-CHANGE: This changes the prefix of the API from
/api/v1 to /api/v2 as this is the successor API of trustification (v1).

Closes: #1112
@github-project-automation github-project-automation bot moved this to Done in Trustify Jan 15, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
UI-V1 parity Tasks needed to get done for V1 UI parity
Projects
Trustify
Status: Done
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

chore: change API version to v2 ctron/trustify
4 participants
@jcrossley3 @ctron @gildub @carlosthe19916