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
Feature request - Versioning #45
Comments
You're right, but how would you want the bundle to manage the versions ? Just by serialising different fields of a class like FOSRest is already doing ? Or something more complicated by serialising different classes ? My thought is that it would be a cool feature, but when you're starting to versioning an API, it's that you need something more than just some fields difference. Can you explain your real use case and what you want to do with versioning ? |
I think I should do two separated issues here.
Then, api versioning is a big controversal subject (nice link). Versioning can be useful when you have a huge breaking change in your endpoint and when your previous endpoint is still beeing used. It's not really interesting to just choose some fields for a version (like in FOSRest) because we can easily do this with Assuming you have a It's not perfect as a real use case, I'll make some more researches on the subject ;). |
A possible solution is to register a new 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. |
Hello @dunglas, I've proposed a simple solution here to manage versioning and retro compatibility changes using a This is in french (sorry ;)) but tutorial + source code is available here: https://codelabs.eleven-labs.com/course/fr/api-versioning-et-retrocompatibilite-avec-symfony/ Do not hesitate if you want me to have a look on how to integrate this solution (which can be easily integrated I think) into API Platform if you are interested. Elsewhere, no problem guys, everyone can implement its own solution :) |
It would be nice to add api versioning with a customizable prefix
/api/1/
or/myapi/v1/
.Thoughts?
The text was updated successfully, but these errors were encountered: