In our current day an age, after a company has an MVP and product market fit, it needs to evolve from being Single Product Oriented to Platform Oriented. This transition has to include the realization that the business functionality baked into the current offering is now something that can use software engineering to scale faster.
Product Centered companies may have some hard time to adapt their mentality towards a Platform Oriented development. Might look like people are not contributing to the greater good but instead is just building internal tools that make little-to-no-sense. Unfortunately is a passage that the company will need to pass in order to leverage its platform to serve better its customers.
APIs (stands for Application Program Interfaces), are the key component of modular and scalable systems. Without clear boundaries, interfaces and contracts, is imposible that system can be modular and scalable. It might become modular, but without clear consistency and enforced contracts, it will become a big spaghetti bowl that is impossible to reuse for new business applications. The same happens in scalability. Without clear boundaries, interfaces and contracts, there is no way to determine were are the system bottlenecks or domains and how you can operate those independently to bring extra support to the business.
Building and “API first” application means that you put first the API constraints to the design of your systems (modules in program or clusters of servers in a cloud-native application) and work your business models around this principles. Consider the following list to build API First Businesses:
Single Responsibility: An API should be clear about the tasks that is in charge of. Avoid common/kitchen-sink approach when designing APIs, as they led to the misusage of the API both in terms of maintenance and consumption. Use clear and common terminology across its interfaces — normally it aligns with the business domain terminology.
Full Compatibility: An API should contain the properties of a full compatible system as much as possible. That means that the API is versioned, has upgrade paths and deprecation notices. Follows a versioned convention that is consistent with the status of the code and keeps the appropriate communication channels to notify the users about any type of change.
Failure Management: APIs should have clear error codes in case of failure. If possible, APIs should self-recover from failure and/or provide ways to recover in case of complete shutdown. This includes operating documents, usage documents and triage tools. As much as possible, API failures should be contained within the responsibilities of the API and should have the minimum set of ripple effects across the system.
Evolvability: APIs should be created with the idea that they will change in the future. This characteristic forces your API to be built in a modular way that in itself is built by modules from which APIs work within the same principles as the system that contains them. APIs should test their behaviors and not their implementations, as well as allow that their interfaces evolve accordingly.
With this principles as constrains while you build a system, you will find yourself thinking of which pieces go together, which might change in the near future and in which layer of your application lifecycle should they live in.
API First companies are more prepared to rapidly evolve their business and find new use cases and business opportunities in the marketplace. Integrations, Collaborations, AddOns, SingleSignOn, etc, require businesses that leverage their systems design as APIs first to provide more value to their customers.
Other sources to read about API First:
The Business Value of API-First Design
Three Principles of API First Design
Understanding the API-First Approach to Building Products
One reply on “A Platform must be API-first”
Interesting article! This applies just to REST APIs or also when there’s a GraphQL API behind?