Closed nphard closed 6 years ago
Usually, the need for versioning of the api comes from the fact that the response payload changes.
Since with PostgREST the client in control of the response body shape (using the select
parameter) different client version can live side by side. This is similar to how things work in the GraphQL ecosystem. Instead of shipping a completely new api, you extend the current one with new capabilities (new columns in the api view, new rpc functions). This way the old clients are not affected and the new clients can take advantage of the new functionality.
If the api changes are so radical that the incremental additions don't make sense, a new version would mean you actually have a new separate api
schema in the database, a separate postgrest instance running that exposes it and a new nginx location that proxies the request to this additional version but i think this is out of scope for this project because it almost looks like a new version would mean a new install of the starter kit
I think it's nice to have api versioning considerations in the starter kit. Like in production for some upgrade of the api, Originally for old client I call from /rest/1.0/xx, but for some upgrade new client, we need /rest/2.0/xx etc.