Intro

Let's begin with a theoretical situation (or actual, on my part).

You want to make an online talking dictionary. This means, in essence, that you want to have users be able to search for a term, find it, and be able to hear the term spoken. But how do you do this? How do you get a database of these word entries? How can you enable the user to browse it?

The answer to that question is an API.

At this point in your coding career, you may have heard the term 'API' tossed around. Maybe you don't know what an API is, or how to implement it in an application. I know I definitely didn't a few months ago. Or maybe you do but you need a refresher.

Regardless, the questions we are going to cover in this post are as follows:

"What is an API anyway? And when/why would I use one?"

Sidenote: We are going to be using the Southern Paiute Dictionary application I developed for demonstrative purposes.

Definition

API stands for Application Programming Interface. It's a set of rules that allow programs to talk to each other.

"What does that even mean?" Well, think of it like this. You're sitting in a Taco Bell drive through and looking at potential food options. Having decided upon a Cheesy Gordita Crunch, you then roll down your window and begin talking to the black box.

You know the one.

An ethereal voice speaks from the box.

"Welcome to Taco Bell. What is your order?"

"A Cheesy Gordita Crunch." You say confidently. After confirming that that is indeed all you want, you pull your car forward to the window where you pay, and then pull your car forward to a final window. Once at this window, it slides open and an employee hands you a brown bag with your Cheesy Gordita Crunch.

How does this analogy relate to an API? Well, the API in this situation is that black box. You began by telling the black box that you wanted a Cheesy Gordita Crunch, and you ended with a Cheesy Gordita Crunch in hand. But you didn't see it being made. You don't know its components and how it was put together. You don't know who made it. In essence, you didn't need to know the details to end up with your Cheesy Gordita Crunch. The black box (and by extension, the staff member manning it) handled that for you.

The black box...or the API.

Types of APIs

"Wait," you say, "what's all this I'm hearing about REST APIs? Are there different types of APIs?

Yes, friend, there certainly are.

'REST' in REST API stands for Representational State Transfer. Those fancy words basically mean that this sort of API uses HTTP (hypertext transfer protocol) to provide support for four different types of API requests: Create, Read, Update, and Delete. Each one of these requests includes a method to complete it, which are 'get', 'post', 'put', and 'delete'.

This is the main type of API you'll hear about, but there are others as well, like SOAP APIs.

I won't go too in depth regarding each type of API; that will be a topic for another post.

Usage

In Our Application

"Ok," You say cautiously, "So how does this apply to coding? Why would I use an API?"

Back to the talking dictionary. You want your webpage to, when the user types in the word 'fold' and hits enter, show all related results to the word 'fold'.

The API enables this. When the user hits enter, the API hears this:

API be like, "Yeah bro. Let me just use a method and handle that for you." It rummages through the database, finds the relevant entries, and then gives them back to the user.

This was what we call a 'get' request and is just one way in which the API can serve you. If we continue on with our talking dictionary, it can also post an entry to the database, let you update previously existing entries, and completely delete an entry from the database altogether. You use the API when you want anything CRUD-dy done within your application.

Security

Another use for APIs is security. When you use an API, the client's data is never fully exposed to a server. On the other end, the client doesn't have access to all of the server's data. The latter is mediated by the methods implemented in the API and the ones the clients choose to use out of those. In our online talking dictionary, the client doesn't have access to all the files in the database. They only have access to ones with the word they used in their query.

APIs are often used to control access to things that an application may not initially have permission to use. A good example of this is when you are opening a e-commerce site and the browser asks you if it can have access to your geographical location. If you don't want those APIs having access to that data, you can choose to decline access.

Conclusion

The API is the middleman between the client and the database, between different applications, etc. APIs are everywhere. There is an API to let a developer enable fingerprint authentication in their app. There is an API to let an application access a user's geographical data. There's even an API to generate memes.

When developing your application, you can make or implement your own API, as was shown in this post. Or you can implement an outside API within your application and use the methods that come with it.

Here is the basic structure of an API (with MongoDB specifically), compliments of Leon Noel.

Let me know your thoughts about APIs and if you know of any particularly useful ones.

The content of my posts is informed by my personal knowledge of a topic, so while I do my best to communicate information correctly, I acknowledge that there may be mistakes. If there are, let me know! I love to learn and improve from my mistakes.