Product Tips and Insights

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.

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.

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.

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.

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.

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:

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.

Author

Caitlin Zucal
Caitlin Zucal is the Marketing Manager at AWH. A graduate of The Ohio State University, she received her degree in International Studies with a concentration in Public Relations and Business. Caitlin is a passionate storyteller and enjoys combining creativity and analytical skills for the enhancement of marketing and product development.