No matter REST, JSON-RPC, or GraphQL, if the data structure (schema) is changed, everything is screwed.
However, with GraphQL you can usually get a type error when you send the query, instead of wondering why the code is accessing a field on undefined.
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.
No matter REST, JSON-RPC, or GraphQL, if the data structure (schema) is changed, everything is screwed.
However, with GraphQL you can usually get a type error when you send the query, instead of wondering why the code is accessing a field on
undefined.When you do REST and follow HATEOAS you can change your data structures. But who's got time for that 😬
I see, GitHub API has HATEOAS. However, if the client code isn't an AI, it still breaks when the schema changes.
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...