But generally, DO NOT tie your external APIs to your data model unless you can can commit to never changing them. (hint: you can't).
--- Edit: The versioning is whole API versioning instead of resource versioning and works by using a different db schema for each version. This is a terrible idea and I wouldn't recommend using this at all
There's no reason you can't change your data model with this. Why do you think you can't?
You create a new schema called "2", change the foo table and release it. As a side effect you also have two versions of bar that are identical. If a client creates a bar+v1 then it goes into the first schema, and if a client creates a bar+v2 then it goes into the second schema.
So you think "fine, I just won't publicise that, clients will only know bar+v1". You continue to make a few more changes to foo, bumping up the version number each time, and then you want to make a change to bar, so you do that and you then have a bar+v1 and a bar+v8.
-- "There's no reason you can't change your data model with this. Why do you think you can't?"
You can with this through the versioning and different schemas. I meant more generally that exposing your DB and then making changes would break consumers of your API, forcing you to freeze your data model instead. Using schemas is a novel solution, horribly hacky but I guess it works.
My understanding is that you use views to manipulate the data going in and out. The views are in the first/second schemas, but the tables that hold the data don't have to be.
And then creating a bar with version 1 to 7 would use the views in each schema to insert it, but it would actually be inserted into the database in schema 1?
But yes, you don't have to have copies of the data in each schema. You only put the view definition into each schema, and the view definition is responsible for reading/putting data from/to the right place. And you bump the version whenever the view definition's columns need to change.