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
Comments
For at least basic use cases you can use serialization groups to do that. |
@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. |
What about running them as separate PHP projects? :) The alternative of
building both versions into one app sounds like it'll just unnecessarily
tie you down in many ways.
…On Thu, 9 Mar 2017, 23:19 Dalibor Karlović, ***@***.***> wrote:
@soyuka <https://github.com/soyuka> have you done the additional research
you mentioned there? :)
The ideas @dunglas <https://github.com/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.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#972 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAhf6_RIm1mEJ5g-zw7yobQiagiv5EWOks5rkBiVgaJpZM4MXALn>
.
|
@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. :) |
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. |
Is there some api version management (except fos version, and jms serializer) in api platform ?
Is it only the parameter api_platform.version ? or is there more ? |
@wadjeroudi it's the parameter, and it's for information |
I can see that this is quite a recurring question, might it be valuable to write down those opinionated thoughts in the doc? |
it is #45 (comment) ^^
|
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.
The text was updated successfully, but these errors were encountered: