Mobile app teams often create app-specific APIs that closely match the design, capabilities, and workflow of their apps, and the devices on which they run. These APIs are quite different from APIs that encapsulate widely used back-end data or functions. For architects looking to create and govern their firm’s overall API design strategy, these are important differences that represent a significant architecture pattern, an instance of the API façade pattern.
The API design and architecture community has also been following with great interest the ongoing saga of the Netflix API redesign, which began in 2012. The redesign has several goals, including reducing chattiness, freeing client-endpoint dev teams to do more agile API design and innovation, and increasing operational flexibility. This is another instance of the same architecture pattern.
API Economy players like Apigee are seeing and responding to this trend, helping their customers understand it and respond to it appropriately, as suggested by a recent webinar delivered by Ed Anuff. In discussing the different kinds of APIs, Ed coined terms for two types of APIs:
- Exposure APIs. These are designed to maximize reuse, encapsulating “back-end” enterprise data and functions.
- Consumption APIs. These are designed for specific “front-end” use cases including mobile, machine-to-machine, etc. (including the Netflix example).
This is a very useful distinction. Ed speaks of creating a consumption API by starting with an exposure-oriented “canonical API,” then trimming it to contain only the data and functions the new API requires. Ignite supports this through a simple process of trimming a canonical service and its message formats, while maintaining the mapping back to the canonical service (which in turn is also mapped through ignite to provider systems). We can depict this as:
Without ignite, it could be quite challenging to keep all these APIs in synch, and to manage change over time as they evolve. Ignite provides the tooling and automation you need to implement this important API Façade pattern, faster and with less effort, obtaining a better and more consistent result. And it helps you reduce the effort to evolve and support your API portfolio over time!
One of the reasons ignite is able to support this way of creating and using APIs is its collaborative working environment. Only when all the relevant stakeholders in the lifecycle of all these APIs can easily collaborate on their design, can your firm gain the flexibility you need for teams building and using consumption APIs, while still meeting your objectives for exposure APIs. Part of the basis for this capability is the recently expanded support for agile development in ignite, which enables agile teams to rapidly evolve their APIs, while staying aligned with canonical APIs.