An API or Application programming interface, allows users or applications to interact with each other, through a clean and well documented system. The goal of an API is to make interactions with the underlying service easier, for both the service itself, and the user calling it. An API can be seen as another layer above the raw service. It acts as a buffer, providing the minimum amount of information required to perform an underlying task, while maintaining an easy to use and understandable interface.

The best way to think of an API is to imagine it as a waiter in a restaurant. When you sit down at a table, a waiter will bring you a menu of all the possible foods and services available at the restaurant. In this analogy, the restaurant represents the application or the service, and the waiter and menu is the API.

You are able to interact with the restaurant (the application) through the use of the waiter and the menu. If you would like the restaurant to make you an omelette, and you can find that on the menu, the waiter will go back to the kitchen and tell the staff to make an omelette for your table.

The API separates you from the backend of the service. You do not need to know how many cooks are in the kitchen. You are completely unaware how many pans were used in the cooking of your omelette. All you know is that when you request an omelette, from the menu (the API), one will be returned to you in short order.

The API is valuable for both parties in this situation. The customer does not want to have to tell the kitchen how to cook an omelette and what ingredients should go in step by step. They would like to select an option that is correct for them, and have it prepared. Additionally, the restaurant wants to be able to cook their omelettes however their heart desires. If they need to have a shift change midway through the cooking process, the customer does not need to know about that or be involved in any way.

What does this analogy look like in a real-world situation? Well, the restaurant could be a company like AWS. AWS has a large number of public APIs that you can interact with, that help you to build your systems and services.

These APIs allow you to create EC2 instances, DynamoDB tables and even build entire multi-tier architectures. You have probably already used the AWS API and might not have even realized it. When you create an EC2 instance in the console, what you are actually doing is having the webpage call the AWS API for you on that button click.

Using the command line is also a way to invoke the AWS API. If you wanted to terminate an EC2 instance you created, you might have done so with the command line using something that looks like this: 

And the reason AWS has this API to help you do these functions is because they don't want you to have to deal with their backend. You should not be responsible for setting up the hypervisors or managing the backend equipment. You just want that ec2 instance to start booting when you use the API and to have it terminate when you are done with it.