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

[Question] API concurrent versioning #972

Closed
dkarlovi opened this issue Mar 8, 2017 · 11 comments
Closed

[Question] API concurrent versioning #972

dkarlovi opened this issue Mar 8, 2017 · 11 comments
Labels

Comments

@dkarlovi
Copy link
Contributor

dkarlovi commented Mar 8, 2017

Is there currently support or a best practice plan to version the API?

In which I mean, how to go about having API v1 and API v2 running in parallel, where v1 is used by legacy clients and required to be running for at least (say) six months alongside v2 which is a new, backward incompatible version.

@dunglas
Copy link
Member

dunglas commented Mar 8, 2017

For at least basic use cases you can use serialization groups to do that.

@dkarlovi
Copy link
Contributor Author

dkarlovi commented Mar 9, 2017

@dunglas that's a start, but seems quite limited, might be wrong, though.

Is this the recommended way of doing it by the project? It seems like a big, important topic to leave up to the end developer.

@soyuka
Copy link
Member

soyuka commented Mar 9, 2017

#45

@dkarlovi
Copy link
Contributor Author

dkarlovi commented Mar 9, 2017

@soyuka have you done the additional research you mentioned there? :)

The ideas @dunglas gave on having a different resource and groups, but same entity seems very interesting, seeing as this is two years old, is this still the preferred way to go? The cookbook entry with a couple of worked out use cases might really be the best solution here.

@teohhanhui
Copy link
Contributor

teohhanhui commented Mar 9, 2017 via email

@dkarlovi
Copy link
Contributor Author

dkarlovi commented Mar 9, 2017

@teohhanhui I don't think that's viable long term as you might need to maintain both versions for a really long time, maybe forever, which increases the possibility of having more than two versions running at the same time, you might have dozens. That means running and debugging (for example) 12 instances of the mostly-the-same-but-not-quite app, sounds like a maintenance nightmare. But you're right, having 12 versions in the same app sounds like a nightmare too. :)

@soyuka
Copy link
Member

soyuka commented Mar 9, 2017

@soyuka have you done the additional research you mentioned there? :)

Yeah, I read about it and from what I remember it had more downsides then upsides. Like you said, if you're maintaining API versions, it often becomes a mess and you'd rather deprecate and update client-relying parts.

Though, I can understand that this can be useful sometimes and my solution would be the same as @teohhanhui. Use two api endpoints, if they point on the same entity, use groups. It's limited, but for the better.

@soyuka soyuka added the wontfix label Mar 15, 2017
@wadjeroudi
Copy link

wadjeroudi commented Mar 30, 2017

Is there some api version management (except fos version, and jms serializer) in api platform ?
Because I see in the doc generated v 0.0.0, how is it defined ?

[ base url: /app_dev.php/sapi , api version: 0.0.0 ]

Is it only the parameter api_platform.version ? or is there more ?

@Simperfit
Copy link
Contributor

@wadjeroudi it's the parameter, and it's for information

@gorghoa
Copy link
Contributor

gorghoa commented Mar 28, 2018

I can see that this is quite a recurring question, might it be valuable to write down those opinionated thoughts in the doc?

@gorghoa
Copy link
Contributor

gorghoa commented Mar 28, 2018

it is #45 (comment) ^^

Not sure if this is a good idea to introduce a feature like versioning in the bundle. It will very difficult to have a generic enough solution. Maybe a cookbook entry with some insights on how to handle such cases will be better.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

7 participants