We have several teams. They need to work on their parts of the project at the same time. How can they be coordinated? Through some kind of API description: one team writes it, the other plans to use it. The document that describes the API is called a contract (nothing to do with a legal contract).
If you practice this a lot and often, then this is Contract-based development. At the same time, contracts often lie separately somehow. For example, in the form of Swagger schemas in a separate git repository. Next, we will discuss exactly this practice.
The main question is how the code and contracts synchronize with each other.
If done manually, this leads to a lot of problems with out-of-sync. Of course, there will be many objections from apologists that there are no problems. But there are problems, they just try not to notice them. Plus, when updating the team, there will be much more problems.
If it is automatic, then the client and server should be generated from the swagger description, and then updated when it is updated.
It is quite easy to do this with a client. Although there are also difficulties – for example, I wrote my template to generate a Kotlin client – https://github.com/stepin/swagger-codegen (because the standard ones did not fit).
With the server, in practice, I have not seen anyone actually update it automatically. So, you need to do the opposite: write a server and generate a swagger description from it. There are no problems after the meeting to update the specification and share it with all interested parties. Yes, there is a limitation that one of the server developers does this, and not anyone who was present at the meeting, but there are some limitations in any approach. As for me, such a restriction is better than swagger, which does not correspond to reality.
In this case, they usually don’t make a separate repository with swagger specifications anymore. And this is no longer called Contract-based development. That’s why I’m against Contract-based development: it’s kind of beautiful in theory, but in practice it’s better in a different way.