Generally speaking, there are four big API questions that every API stakeholder needs to answer:
- Discovery: How do I know there’s an API?
- Documentation: What does the API do, and how?
- Authorization: How do I get to use the API?
- Quality/performance monitoring: Does the API do what it is supposed to do?
An experienced API engineering team can help with these issues. But none of them are particularly quick, easy or cheap matters to handle.
Discovery
You can look somewhere like Programmable Web to find out what APIs are out there. It currently lists more than 17,461 APIs. That’s a lot of APIs, but there are a lot more out there. Even with a curated list, it’s easy to miss something that might be of interest.
Documentation
If you do find that you might want to use, the documentation is often confusing, incomplete or just plain wrong. An example of the API is worth a thousand words of formal definition. But I don’t think my opinion is shared with the bulk of software engineers!
Authorization
Setting up an API that uses vanilla OAuth2 authorization can be a blast. Provided, of course, that the API provider lets you sign for their developer program without any fuss, register your test app and get the Client ID and Client Secret.
You can be up and running in less than ten minutes if there are clear descriptions of the API endpoints in the documentation. But all too often, there are gotchas. A non-standard implementation of OAuth2 or something weird going on with the scopes or tokens or some bizarre authentication scheme all of the provider’s own devising. Security by obfuscation, eh?
Quality/Performance Monitoring
Quality/performance monitoring is the easiest problem to solve. Just use APIContext! We’re constantly enhancing our products and services so we can answer your big API questions. There’s always more to understand about your APIs.
Image by Daniel Novta | CC BY 2.0
