There are many technical and business factors to consider when selecting a Web API. I spend a great deal of time hunting for the best services and their associated APIs to provide a specific capability within the parameters and constraints of a given project and organization. This is not a particularly scientific list but is based on dozens of projects done over many years. Here are the features that I pay the most attention to when selecting an API:
Does it do what I need: This might be a “duh” moment but I really look for the
“service” first and the API (the interface to the service) second. Regardless
how slick the API is, if the service is not the right fit for the use case I
avoid using it. With the amazing state of SaaS offerings it is
incredibly rare that I can’t find a service (actually 3 services) that do
specifically what I need, the way I need it. My personal favorite is Stripe for
payments. I picked Stripe first because the service offering was the most attractive and
second because it nails each of the other criteria on my list.
Does it have a strong community: Community is incredibly important because it
shows the level of dedication of the API provider to foster a community as well
as the number of skilled developers in the same boat. I measure this by
indicators such as activity (in terms of Answers) on StackOverflow and project activity on GitHub
(issue turnover, pull requests, stargazers).
Does it have a client library in my language: I have no love for writing tedious Unirest
code (although I do love Unirest!). I look for APIs that provide
a language native experience for consuming and interacting with the service.
This let’s me stay within my development language and (for a well designed library)
speak more business logic and less technicalities (let me catch meaningful
exceptions not write switch statements for HTTP response codes). I have used a language native client library for every commercial API I have consumed. My colleague Alek wrote a previous post diving into more details on this topic: Why APIs need SDKs??
Does it look like the other APIs I’m using: This is important because it
prevents my head from exploding when coming back to a code base or expanding a
project to new team members. APIs have a certain feel to them (i.e. are they
truly RESTful, do they make heavy use of callbacks, how are they versioned,
what data formats are supported) which is translated into the development style
of the supporting code. I favor picking APIs that share common attributes.
Have I used it before: Ok, so creature of habit! But clearly this is a huge
boost to productivity if I can use the same API for a task that I used last time.
Not to mention I can look at my own code that made use of the API and possibly
reuse proprietary wrapping. The important aspect here is really the
familiarity with the underlying service. If I know how to operate the service
and it has proven reliable and effective then I can have more fun writing code
and spend less time on support tickets!
With that said, I’m really interested to know what YOU think is important when
selecting an API? Do you look for similar things as I do or do you use an
entirely different selection process?
Thanks for taking the time to share your ideas!