There are a number of ways to create or architect an API but one of the most common you will hear about is REST. I don't want to dive very deep into this topic, but I do want to take some time to make a distinction between HTTP and REST. These are two distinct things, but are sometimes used interchangeably by accident.

HTTP is a communication protocol as we have just gone over. So an HTTP API is just an API ( a system that helps two software entities communicate with each other ) that uses HTTP to communicate and doesn't have any other major modifications or constraints placed upon it.

A REST API or RESTful API can be thought of as a set of constraints placed on the communication system that helps to define the way communication should take place.

REST stands for REpresentational State Transfer.  REST is almost like an architectural style, it doesn't care about the building materials per say. It can be used with HTTP, FTP, or any other communication protocol. REST just happens to be very commonly used with HTTP.

There are quite a few components required when creating a RESTful system or API but here are the major bits.

Interactions between the server and the client should be described only using hypertext.

The coupling between the client and the server should be as lightweight, or loose, as possible. This means that the server or the client should make NO assumptions about each other.

The server should not store information about any requested information. The requests should be independent of each other, and should always give the same results 

Another key architectural concept with RESTful systems is that clients can only access resources by using a URI. 

The service, or server will then transfer a representation of the state of the requested resource to the client who called it. Hence the name - REpresentational State Transfer (REST). 

This state information is normally conveyed as a JSON object that can be parsed and used as needed.

Here is a quick example of using a URI to get some information:

Imagine we wanted to get a listing of all customers from our database. If we have an API already created, we could use the API to grab the information.

Our request would look something like this.

While the body of the response from the Server might look something like this: 

Here we can see the API has returned all of the customers from its backend database. We can see Finn, Jake, and Fire Princess.

Although you might just want to get a specific customer if you already knew about their ID

Our request for that would look something like. And would return something in this form.

Overall an API is a fairly straightforward system that can really help you build out functionality for your business, both internally and externally. 

And one of the best ways to drive your API forward is to make sure you use it within your own systems, and not just for your customers. This idea of ‘Eating your own dog food’ helps to ensure that your product is usable and well maintained. If you plan to create a public API for your customers to use, make sure it is something that you would be willing to use as well.