I’ve been leaning towards the idea of Consumer-Driven Contracts in order to allow separate API consumers evolve on their own. To approach this concept initially I’m tempted to dip my toes in slightly by creating separate API paths for specific consumers (ex. GET api/SuperCresMobileApp/puppets/olly, GET api/BigPaternerIntegration/puppets/olly). The idea is that initially it will be easier to implement integration tests for these separate paths and to share the back-end implementation by baking them into the same service. Later I could see that the shared implementation could be separated into a service itself and the consumer driven parts could be set up mostly as façades.
Is this a reasonable way to approach APIs build with consumer-driven contracts?
Other resources:
* Why you should use Consumer-Driven Contracts for Microservice integration tests