An API solution has a certain complexity. Complexity does not simply go away — it has to be handled somewhere, by someone. Thus, the complexity of the API solution can either be dealt with in the client or in the API.
If the complexity is dealt with in the client, the task of the API provider is simple and the task of the API consumer is difficult. This is usually the result of the inside-out approach and leads to sub-optimal APIs that make the live of the API consumer unnecessarily hard.
If the complexity is dealt with in the API, the task of the API provider is difficult. However, the task of the API consumer is simple. This is usually the result of the outside-in approach. An outside-in approach has a higher chance of producing APIs that consumers love and despite the difficulties for the API provider, it is the recommended approach.
Since building consumer-oriented APIs with the outside-in approach is rather difficult for the API provider, as much methodological support as possible should be given to the API provider. This includes contract-first design, agile design and simulation-based design.
Applying the contract-first ideas to API design, allows for a clear separation of the responsibility between API and client.
Applying an agile approach can help to navigate in situations with unclear or vague requirements, but should only be applied until the API is published.
Applying ideas of the simulation approach allows for breaking up the dependencies during development. It allows for an independent development of client and API, despite the dependencies between them.
If you need to build APIs, you might be interested in my new book on API architecture and API methodology.
