Scenario 1, this i think models a real life scenario of how an api would evolve over time and we can test it it's actually possible to model versioning using shcemas
Start with 3 schemas that hold the versions of the api 1,2,3
- v1 just holds a few tables with relations (let's go with companies/users/clients/projects/tasks (+the intermediat tables for many/many relations), i know the domain so i can spot the problems and provide scenarios) the relations are companies>clients>projects>tasks, companies>users, projects<>users the fields are basically id,name,name_id (this is the fk)
- v2 needs to do this
- change the name of the foreign keys from client_id to client_fk (new CTO that likes it that way :)) )
- add a new BOOL field for the project table called "archived"
- change the type of a field from the client table ("archived" change from int to bool)
- remove column "users.name" and add "users.first_name" and "users.last_name"
- v3 needs to do this
- add a new relation users<>tasks (product manager decided we also want to be able to assign users to tasks, not just projects)
the tests should test this
- start separate instances with the parameter set to 3,2,1 then 2,1 then 1 and check that in each case the OPTTIONS request "sees" the correct tables/columns
- start an instance with 3,2,1 and check that all relations work (by embeding parents and children)
- start an instance with 2,1 and check that there is no relations between users<>tasks
This is how an api would evolve but i am not sure how you can make things like "split name into first_name last_name" between versions and still have both versions run at the same time