🔗Overview
Traditional product design is channel and device centric. But users inhabit a multi-channel, multi-device world.
Channel and/or device centric product design results in duplicated effort and wasted engineering work. API-first development is focused on removing this technical debt through the separation of the data backend and the data consuming front end.
API-first development is the idea that whenever you are developing a piece of shared functionality for your organization it should be exposed as a RESTful HTTP(S) API to all of your other developers. Rather than creating a library or module that needs to be added to all code bases requiring the functionality, developers can consume all the necessary functionality through the API. Having developers consume all functionality through an API enforces separation of concerns and hides internal complexity.
COPE stands for Create Once, Publish Everywhere. It is about reducing editorial overhead by freeing content for use in multiple different contexts. Simply put, COPE separates data from design, making your content reusable and future-proof for new devices or platforms.
Taking an API-first development approach enables COPE and brings several additional benefits:
- Separation of concerns
- Scalability
- Reduction of language barriers
- Developer liberation and specialization
- Openness and future consumer availability
- Modularity
🔗1. Separation of concerns
API-first development is the formal separation of the front end from the back end.
Similar to the Model View Controller paradigm, by decoupling data from logic from presentation, it forces a better code architecture, which in the long term decreases your technical debt. API-first development makes it easy to push data to multiple views, regardless of size or functionality.
🔗2. Scalability
Completely separating your front end and back end codebases helps to simplify future scalability by enabling you to scale platform components independently of each other. It allows for the client and server to sit behind their own load balancers and in their own infrastructure, giving you the ability to scale on a micro-level which brings flexibility (for example your data could be stored centrally while your client is hosted in multiple geographical locations) and cost savings.
🔗3. Reduction of language barriers
Your API should be a reflection of your business logic. Separating it out gives you the capability of expanding into different channels and in support of different devices while utilising the same backend.
Your API acts as a universal language, which any of your clients can interact with. Even as you expand, every team will be speaking and understanding the same language. The expectations are always the same: same successes, same errors. Better yet, everybody knows JSON and almost everyone is up to speed with REST, so the API is globally understood.
🔗4. Developer liberation and specialization
API-first development liberates developers. The only thing application developers need to know is the request/response sequences of each API endpoint and any potential error codes. The same goes for mobile developers, and any other type of developer for that matter.
Industries move forward when knowledge can be ‘black boxed’. Imagine if, to build a web application, you had to know how to build a microchip from scratch. Thanks to specialization and division of labor all you need to focus on is the code. This is the advantage of API-first development.
The approach frees up the front end development team to focus on a few specific ways to interact with the data, and the back end team can focus on providing it in a RESTful manner.
🔗5. Openness and future consumer availability
API-first makes opening your API for public consumption simple. And as a client of our own API, as you add more functionality you will be in a position to offer it to consumers without any additional overhead.
🔗6. Modularity
Why limit yourself to just one source of data? With modern web practices you can easily combine multiple APIs to make a powerful product quickly. And if your needs change, so can the your platform, by simply adding or removing an API.
