One API, Many Facades?

One API, Many Facades?: "Web APIs increasingly have several kinds of consumers with different needs. Microservice architectures can encourage us to deploy fine-grained API facades for those needs (the so-called experience APIs or BfF patterns), but this can become an anti-pattern if you have too many distinct consumers to please, especially if you’ve got only a small team to take care of all those front ends.

Be sure to do the math! Before going one way or another, you have to study the cost of your options and whether or not you can support them. Creating different variants of an API has a cost, for the implementor as well as for the consumer, that depends on the adopted strategy. Also, once you’ve unleashed your API and given it to its consumers, perhaps it’s also time to rethink  and refactor this API, as maybe you didn’t take those special device or consumer requirements well enough into account during the design phase.

If you have dedicated teams for these API facades, then it’s an option to consider. When you don’t have that luxury, there are other ways to customize payloads for your consumers without the induced complexity, with simple tricks like field filtering or the Prefer header up to full-blown solutions like custom media types or specifications like GraphQL.

But you don’t necessarily need to fire the big guns, and could opt for a middle path: one main, full API plus one or two variants for mobile devices, and you are likely going to meet the requirements of all your consumers. Consider including a pinch of field filtering, and everybody will be happy with your APIs!"



'via Blog this'