An API (application programming interface) is an interface that allows software programs to communicate with each other. The communication barrier between programs has become thinner as APIs have evolved over the recent decades, like our languages have over the years. At SoftLayer, we have plenty of opportunities to interact with many different APIs from various companies. Some of us work with a driver API, some work with SOAP, or some work with XML-RPC for some projects. If you’re our customer, I bet you can easily imagine the number of APIs we use by looking at the products and services we offer. Not only are we a large API consumer, but we also provide a great number of APIs to our own customers. It seems that the interaction between software programs evolves just like our lives.
It’s hard to survive alone in this world. We are social beings, and we need others for interaction. A software program pretty much works the same way. There is no program that is a know-it-all or do-it-all. If there were one like that, I would not have a job. Software can expand its capabilities by working with other programs just like we, as humans, help each other. APIs act as a communication tool like our languages; and, by the way, there are many dialects too.
When a program starts to interact with another through API, it can be compared to a marriage. They are stuck together. However, programs can marry many others. When two programs start to interact, one cannot change its API without the other knowing. It would be as if your wife started talking to you in Danish all of a sudden. Even a small change in an API can cause a very bad outcome. Imagine that your wife told you to throw your socks in the laundry basket and you have been following this rule for years. Can you imagine what would happen if you left your socks by the bed one day? No, it simply wouldn’t work. If you really need to change the rule, it’s time to consider a divorce, in other words, API version 2. As I mentioned, a program can have multiple partners and you can’t expect them to follow new rules all at once. Your best bet would be to write a version 2 and keep the original version for old times’ sake. Trust me, people are very hesitant when it comes to changing their routine, including me. (Why should I touch a working program just because you updated YOUR API?)
Most APIs that I have used and seen are wonderful. I have seen APIs that work like a jack-of-all-trades, trying to do everything for me, but I didn’t like it. I would not like a BLT with onions, eggs and mustard. I just wanted a B.L.T, period! I have also seen APIs that require too many prerequisite steps (invocations) to get a simple result. How many times must you get transferred until you finally get someone to help with your phone bill? Jeez!
Ok, enough of these funny comparisons. I, a biased user, have listed below what I think is a good API:
- A good API should not change often. If change is inevitable, it should give you plenty of notice and allow backward compatibility.
- A good API should explain why it couldn’t work instead of the infamous “Error: -1”.
- A good API should have good documentation, so you’re not left scratching your head.
- A good API is accessible by different platforms.
- A good API should be stable.
- A good API should be simple and comprehensive. It should do what it says it does and it should do it well. Prefer “powerOn()” over “powerOnWhenIdleAndStartServices()”.
A good API implies the readiness of communication with other programs and other companies. It will broaden opportunities for your programs and organization to work with others, just like a person with good communication skills has a better chance of fitting in our society.