APIs (application programming interfaces) have quickly gone from a niche developer tool to a focal point of business strategies for everything from marketing and sales to partnerships and customer service.
While public APIs are business-driven tools, they’re still pieces of software and need to be approached with the same level of detail and planning as a software development project. Answer these questions and you’ll be ready to engage a skilled API developer to help you get started.
1. What is the business value of your API?
Private APIs are almost always geared toward improving back-end systems and internal software. But for public APIs, establishing the business value of your API is an important first step that will guide how you structure the entire project.
Determine why you’re building your public API and what value (monetary or otherwise) it’s bringing to your business. This can be established through user stories, use cases, the potential for new revenue, strengthening partnerships, streamlining vendor onboarding, or improving the way you interface with clients. Are you looking for better mobile market penetration? Monetization? This is also a good time to take a stab at a cost-benefit analysis. APIs aren’t cheap; will it be worth the effort to build one for your business? It’s difficult to predict how developers will respond to your API, but you’ll be aware of potential challenges and have them on your radar when you get deeper into planning.
2. Who is your API audience, and what do they want from your API?
Who are the developers you’re creating it for? What tech do they use? How will they be using your API, and what actions should it perform? Knowing who your audience is first will help you determine the request-response model that will fit your API best, and allow you to design your API specifically for them.
Also, know what your audience is looking for from your software so you know how to structure the data in a way that is organized, and efficient, and ultimately puts less stress on your and their systems. User experience (UX) can be a major factor in the success of your API and will drive a few of your more technical decisions. Developers are the primary consumers of APIs, so be sure to provide them with adequate documentation so your API is easy to work with.
3. What are your API’s affordances?
What can people do with your API—now, and later? This will determine the security and structure of your API, and help you lay out what assets will be exposed and how. If you’re building an API to streamline how you work with partners (say to contribute more seamlessly to a supply chain), this will shape permissions.
For organizations in industries with specific compliance or regulatory requirements, this is a time to double-check that you’re able to share the assets you’re granting access to.
4. What will your software schema and data format be?
This isn’t the “be-all, end-all” of your API’s design, but it’s important. Your use cases will drive the most effective schema design, which helps you organize your API.
How will your data be formatted, JSON or XML? JSON (a subset of JavaScript) is very popular for APIs because it’s more compact and can interface well with JavaScript-based web apps. XML, while more powerful, requires more work from programmers. Also, how will you account for security and stability?
5. Do you need to set use limits on your API?
Most open APIs—both public and private—need some line of defense from overuse and abuse to protect the server and control costs. These can be anything from rate limits and throttling to data transmission limits and call volume by application limits. Discuss this with your customer service and DevOps teams to help you anticipate the volume and establish the limit that works best for your business needs and users.
6. Will you use REST or SOAP?
These two “styles” of writing APIs speak to the architecture of an API, each with its benefits and implications for how your API will communicate with the server. The REST API paradigm is based on the HTTP protocol and can be simple to build and scale; SOAP (Simple Object Access Protocol) is a bit more complex.
Learn more about the differences between these two API architectures.
7. Are you planning to monetize your API?
The traffic measures listed above can also be used to let you monetize your API. If someone wants more calls than their existing agreement allows, they can pay for more calls (e.g., a “freemium” model)—and so on.
8. How will you measure the success of your API?
When it comes time to establish an ROI for your API (which likely won’t be an exact science), knowing what metrics to gather and analyze will help you frame out a way to tell how well your API is doing.
Remember: Once you’ve built your public API and exposed your assets to developers to work with, it’s important to maintain performance and stability. They’re relying on your services for theirs to work properly.
