Ever since launching this site I’ve received many emails with ideas for other comparisons. With thousands of public APIs there are many ways one could compare APIs. How do I focus in on only the APIs that every developer needs to know? I think about beer.
Let’s say you’re at a bar and ordering a pitcher of your favorite beer. (If you don’t drink beer, feel free to substitute your beverage of choice). You set the pitcher down at your table, because hopefully you are sharing the beer with others. Right? That’s a lot of beer for one person.
So, you and your friends have a pitcher of beer sitting on the table. Like this…
Why are you here? For the beer, obviously.
Yes, you like spending time with your friends, but you could do that anywhere. The table itself is unlikely to have influenced your decision. The beer, in that pitcher in front of you, is likely the thing that has the most interest.
For the vast majority of APIs, they are not the beer in this scenario.
Most APIs are the table. A sturdy foundation, certainly. A place to gather around, yes. But not likely the main attraction. The beer, in the case of most APIs, is a service that the API supports and extends. The service is likely even built on the API.
These “table APIs” are certainly interesting. These are the APIs covered in my Business User’s Introduction to APIs. If you’re a Salesforce user, for example, you care about using the Salesforce API. If Google Docs is at the center of your business life, you definitely want to be able to automate your workflow.
There are many, many decisions that drive whether you choose a service. The service’s API is unlikely to make or break your decision to use it over its competitors. The service itself is what you care about. The service is the beer.
If the majority of APIs support a service, that leaves the minority of APIs where the API is the service.
The APIs every developer needs to know fit this criteria. The API is the beer. It’s the reason you’ve come to the table.
Sales gets to decide which CRM to use. Marketing gets to decide which newsletter software to use. When the API is the service, developers get to decide which brand of beer to buy.
It’s through that lens that I’ll choose which APIs to compare, so that I can help developers make (and defend) the right choice for their situation.
Now, who needs a drink?