Design is all about understanding and remembering the purpose of what you are building. A convertible is fun to drive, but pretty useless if you need to bring some lumber back from the store – a pickup would work better. Unsurprisingly, APIs are no different.
Some APIs need to simply provide a more convenient way of accessing and updating information… they wrap up other systems. Their advantage is they make it easier to work with the system – using familiar HTTP calls rather than needing complex client libraries, they might provide caching or pool connections to make access more efficient – but the consumer doesn’t need to worry about the details.
Other APIs aim to provide business capabilities, supporting the activities a customer performs or the processes the business needs in order to operate. They aim to make the business streamlined and flexible – not being tied to specific provider systems. They may provide aggregated views, expose the results of business logic or describe the business using common business vocabulary.
Trying to combine a pickup and a convertible will only lead to something neither great for enjoyment nor great for carrying capacity.
So in reality it’s not ideal to combine the two different goals into a single API – otherwise you risk tying the business to specific back-ends. But likewise simply wrapping systems with an API but using business vocabulary forces consumers to implement business logic, and doesn’t make sense unless you want chaos to reign as the logic is duplicated.
So while the exposure API only approach may appear to be a good starting point, the reality is that it may give little or no benefit over point-to-point integrations without business capability APIs. At best each integration may be slightly easier because of common technology, and at worse it simply shifts complexity to API consumers forcing duplicating business logic.