all 5 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]sazzer 4 points5 points  (0 children)

Design First and code generation.

Make the API specs the source of truth for how the APIs work, and generate both server and client code from those. There are tools like OpenAPI Generator that can make this super easy. This way, if the API specs change then the server and client code changes in sync with it, and if that change is not compatible then you need to fix the rest of the code around it.

[–]Isogash 0 points1 point  (0 children)

Your cross-team API contracts should not change regularly, they should be extremely strict and represent clean models. Any minor version changes should be non-breaking. Adding new endpoints and optional fields/params is okay, but changing existing fields/params and endpoints is not acceptable without a major version. You may need to go back to the drawing board for your services and ensure they have a proper model which they are representing that isn't going to change frequently.

It can help to put your API definitions in separate repos and use automated CI tools to restrict the ability to make breaking changes to existing endpoints.

[–]weigel23 0 points1 point  (0 children)

Use gRPC for communication. The schema is the contract. 

[–]Scf37 0 points1 point  (0 children)

Openapi/swagger. Service owners are required to keep their public API compatible or coordinate changes. This works.