Submit support requests and browse self-service resources.
Defining API requirements is an important step to developing your APIs.
But what are API requirements? And how do you define API requirements?
That's what we break down in this blog.
API requirements include functional requirements (what your API should do) and nonfunctional requirements (how your API should perform in terms of service level agreements). On top of that, API requirements also include a third type — the way your system implements requirements.
The illustration below shows this breakdown of API requirements from functional to nonfunctional to implementation.
Requirements For Your API Management SolutionCheck out The Forrester Wave™: API Management Solutions, Q3 2020 report to learn about key requirements for your API management solution.get the Report
Check out The Forrester Wave™: API Management Solutions, Q3 2020 report to learn about key requirements for your API management solution.
get the Report
Here's how to define your API requirements.
It's important to consider the complete API lifecycle, too.
Functional requirements define what the API does and how the API will be used.
The way in which the API will be used affects several issues such as the technology choices, regulatory issues, and security. For example, an API that’s being used to perform financial transactions will have more constraints than one delivering advertisements.
Some examples of how APIs will be used include the following functional requirements:
There are two big differences between functional and non-functional requirements:
Because of the differences between them, it’s important to separate out these two types of requirements.
Availability, scalability, logging, security, and performance are all critical to the successful use of an API. But none of them have anything to do with the business process or domain of the API’s resource.
Here are some examples of nonfunctional API requirements.
It's important to address nonfunctional compatibility for APIs. For example, if a particular security mechanism was applied to an API, but other consumers required a different security mechanism, that API is not reusable. This is true for any non-functional capability, including logging and failover.
But functional and nonfunctional aren't the only requirements for APIs. There are also implementation requirements — which are typically heavy on security.
There are lots of examples of API implementation requirements, but let’s just take a look at a couple of security specifics for SOAP and REST.
The implementation specific requirements are the way in which you meet functional or nonfunctional requirements for a particular API implementation. There is a big difference between an API and an API implementation. In fact a single API could have lots of implementations.
Even more important than the idea of implementation specific requirements (which I’ll abbreviate as ISRs from now) is the question:
Does the API address functional requirements? Or are the functional requirements really addressed by the system that exposes the API?
It’s one thing if you happen to be Facebook or Twitter and have a platform that was built with exposing an API in mind — or or it was built with an API-first mindset. But in most enterprises that won’t be the case.
You will have a whole bunch of different enterprise applications, all of which deliver some valuable capabilities. But what you need to do is deliver real business value to your partners and customers by delivering an API that uses functionality from many of these applications.
In this case, most of your functional requirements will be met by the applications themselves with your service or API platform tweaking a few things in the process of delivering the API.
What you need to focus on is how you can ensure that your API will meet its functional and implementation specific requirements.
In many cases your API platform will be responsible for creating the various different implementations. In this case, you need to ensure that your API platform can enforce security and QoS policies. But it also needs to take multiple backed services of different types and create a consistent API interface that it can expose as SOAP, REST/XML, REST/JSON, WebSockets, AMQP — and whatever the industry will throw at you next.
Akana provides the best platform to fulfill your API requirements. That's because Akana makes it easy to create, publish, consume, and monetize APIs.
Because Akana makes it so easy to deploy APIs, you can achieve faster-time-to-market. Plus, you can automatically apply security policies. And you'll get the support you need to drive your API strategy forward.
On top of all that, Akana makes it easy to deliver real business value to your organization. Seriously — check out how much you can save based on your API performance indicators >>
See for yourself why Forrester ranked Akana as a leader in API management — and the top vendor for API policy and security. Try Akana free for 30 days.
Start Trial ▶️ Watch a Demo First
This blog was originally published in 2014. It has been updated for accuracy and comprehensiveness.