Agile is the new definition of digital business, but it’s more than a buzzword — it’s a transformation. To truly become agile, organizations must think and act differently, loosen controls, and give developers the opportunity to think more creatively. That’s where a strong API strategy comes in.
At The Path to Agility™ in Columbus, OH, AWH founder and principal, Chris Slee, discussed the value of APIs in product development and presented his API Manifesto:
- API as a discipline over API as an access layer
- Shared standards over ad hoc usage
- Secure thinking over adding security later
- Design for all consumers over built for the screens
- Contracts with the consumers over breaking changes
- Documentation and examples over discovery during consumption
- APIs to mitigate technical debt over complete system rewrites
According to Slee, there are seven core components of the API Manifesto, all of which are critical to how APIs tie into sustainable business agility:
- Treat the API as a first-class citizen
An API must be treated as a first-class citizen of any data architecture. At AWH, we have an entire team specifically dedicated to API development. With an “API First” approach, you can avoid the temptation of creating ad-hoc APIs as “plumbing” for web or mobile applications.
2. Governance by strategy and standards
Many companies develop APIs for point projects only to be left with hundreds of redundant APIs with little commonality. A strong approach to API development and standards can prevent this issue. As a best practice, establish governance around the creation of API strategy and standards, as well as checkpoints throughout development to identify strategic value and find opportunities for reusability.
3. Operational security is a holistic endeavor
By thinking of operational security as a singular approach rather than a holistic endeavor, APIs are placed in far more danger than necessary. Web developer and author, Kristopher Sandoval, explained API security this way: consider security from the perspective of a king defending his castle. You know invaders are coming — would you place all your valuables in one fortress defended with the entirety of your army at a single gate? Or, would you spread your wealth across multiple fortresses each protected by armed warriors and a gate? Most of us would choose option two. The same multi-layered approach must be taken to secure your API.
4. Design APIs for the rapid consumption of all perspective consumers, not one consumer
APIs interact with multitudes of consumers — a device, web application, mobile app, and more. Many times, APIs are screen-based to support the applications. Developers focus on the screen that will consume the API, build the API to send data back to the screen, and then the backend systems which assemble data and prepare it for the screen. Because APIs are specifically targeted, it becomes difficult to reuse them. An API design must be its own entity, built to be a true citizen of the application stack, not just a conduit for data transfer.
5. Consumption is a contract that is unbreakable
Once an API is published and consumed — used in any way for an application — it exists forever, even if it was poorly designed. Fortunately, there is nothing wrong with introducing a new version of an API. As part of your API strategy, plan for a versioning process. This will give you the opportunity to upgrade APIs as needed.
6. Communicate the API through clear working examples
In today’s world, you need robust API documentation on how they work with samples in multiple languages. We use tools like MuleSoft to write Yaml, a descriptive language to document APIs, as well as an open-source tool called Slate, which allows us to build APIs and write examples.
With solid documentation, you will have fewer people contacting you with questions. This will mean less frustration for your developers and users and more time to focus on building your next great product. Here are some samples of strong API documentation:
7. The sins of a system can be mitigated in the API
We often run into monolithic legacy applications. This is very common because that’s how developers used to write code. Now, we can go in with an API layer and begin to separate the monolithic application by leveraging APIs and then consuming APIs in the server.
