Yes, github is not a bad example. If you built your client according to the github API documentation it'll probably never break. Because then you alway specify the version of the resources you're dealing with in the media type header, see docs.github.com/en/free-pro-team@l...
Versioning based on media types prevents stuff to break when an API introduces breaking changes. However, it only works when the client is aware of it and adheres to this flow. Also it gets more complex on the server side, as you have to be able to provide multiple versions of the same resource at the same time. That's what I meant with "who's got time for this"...
Yes, and that's why you have this problem. I just want to point out that it is possible to introduce breaking changes to a REST API without breaking clients...
Log in to continue
We're a place where coders share, stay up-to-date and grow their careers.
Yes, github is not a bad example. If you built your client according to the github API documentation it'll probably never break. Because then you alway specify the version of the resources you're dealing with in the media type header, see docs.github.com/en/free-pro-team@l...
Versioning based on media types prevents stuff to break when an API introduces breaking changes. However, it only works when the client is aware of it and adheres to this flow. Also it gets more complex on the server side, as you have to be able to provide multiple versions of the same resource at the same time. That's what I meant with "who's got time for this"...
This is when the server side maintains each version indefinitely. I'm developing the server and I don't want to do that.
Yes, and that's why you have this problem. I just want to point out that it is possible to introduce breaking changes to a REST API without breaking clients...