Introduction to APIs – Part 1
By Alexandra Martinez
Have you heard the term API before, but feel like you can’t fully describe what it means? Does it seem like everyone in technology is leaning towards having APIs within their systems, and it sounds like a big deal, but you’re not sure why that is?
Don’t worry. We’ve all been there. By the end of this two-part blog, you’ll have a better understanding of what an API is and why it’s relevant in today’s world.
API defined
If you search what API stands for, you’ll find this: Application Programming Interface – a set of subroutine definitions, communication protocols, and tools for building software (source).
An API has four aspects:
- Inputs
- Operations
- Outputs
- Data Types
All APIs have inputs, that consist of the information you send to the API in the form of a request.
They will also have operations, that tell the API what you expect it to do with your input request.
Outputs are what the API returns after it processes the inputs and operations you send. The information is processed and returned in the form of a response.
Finally, data types are how you want your data to be processed. Your API could be using a very simple text structure for the user to form a request, like a CSV file; or it could be using a very complex object, like an XML or Java object.
For example:
Let’s say you want to use an API that will return your employees’ first day of employment within the company. The API can take a CSV file, like the following three column form:
Once you send that request to your API, it will return a CSV file with the information you requested, in the API’s response. Something like this:
Now, let’s say you don’t want to use a CSV file and you know that the same API also takes a chunk of code in a JSON format; in case you would like to have this data in a different format.
If you were to use JSON, this is how the exact same request and response would look:
As you can see, it’s the same data being processed, but it’s sending a different request data type and getting a different response data type.
Functionality is independent of implementation
You’ll notice I didn’t explain the implementation part in the above diagram. The implementation is the actual code inside the API. You can use Twitter’s API to retrieve your account’s tweets to show them in your website, but you don’t actually need to know what all the code inside is doing, or how it’s built; you just care about what you request (to retrieve the tweets from your timeline) and what it responds (your actual tweets).
I’ll give you a simpler example to explain this: a calculator.
When you use a calculator, you’re requesting input numbers and operations (1 + 1) and you expect to get the response of those (1 + 1 = 2). You likely don’t really care on how the calculator processes this information; you just need to get a response for your request. The same happens with APIs.
Now, why is it that the functionality does not depend on the implementation? This is because the API may change its code, but you’ll never notice because it’s still giving you the same response you expect. The functionality doesn’t necessarily change even if you replace all the implementation. Another way to say this is: how it works doesn’t matter nearly as much as the fact that it works every time.
I hope this was informative and you understand this “API thing” a bit more now. In part two of this blog, we talk about why APIs are important for your business!
About the author
Made in Mexico, Alexandra enjoys learning new technologies and is always looking for new challenges. She loves statistics because she’s bad at them, so they keep her alive (an eternal challenge). Her natural habitat, however, involves watching Netflix and playing video games.
