Maybe you have seen a section like the one on Stripe's homepage:
"Whew, not my section" you think? Here is the good news: You don't need to read such pages in order to still use an API for your own benefit. If you remember nothing else, this is the most important thing to take with you:
APIs are used to exchange information between different programs.
API stands for Application Programming Interface. It is one way how programs can communicate with each other, without having to sit in the same code base or even on the same server. There are other ways to get information across but APIs have become essential in many software- and data-driven environments. Much of what happens when you are browsing the Web or using apps on your phone is based on such APIs.
Going down the rabbit hole
In many cases, automating your tasks such as in the example above is sufficient to cover a huge range of processes and applications. If you want to understand a few more technical details, read on!
Requests and HTTP
It took me a long time to wrap my head around these two connected concepts when I first entered the world of the Web. The only explanation I have is that I had often seen "HTTP 400 Bad Request", followed by some form of disappointment that I could not reach the site that I wanted. Later on, I learned that those two are not that bad after all.
Making a request is similar to asking a question, except that the question has to contain certain elements (words) and follow a certain structure (grammar). The question goes from the client (your browser) to the server (a website database or website). In fact, every time you enter a URL into your browser, you are making a request.
There are different types of requests that are relevant for working with APIs, also known as request verbs. The most common ones are the following:
- GET: Request a specific resource, or list of resources
- POST: Send data to an API to create a new resource
- DELETE: Request a specific resource to be deleted
- PUT: Send data to an API to update an existing resource
Let's just focus on the first two for now, GET and POST. When using GET, the server (see above!) is prompted with responding to a certain question: You want to see a list of your Facebook friends? That's a GET request in the background! In turn, when uploading a new picture to Instagram, that is a POST request to their servers: You send over some data from your client (your mobile app) to their database.
Responses and JSON
Unless there was an error in the request or data transfer, servers are kind enough to send you a response. In most cases nowadays, this response will be in the JSON format. This format is relatively easy to read and write, even if it looks a little bit odd at first
If you want to go really wild, check out the official documentation (great content and great 90s-websites throwback).
In any case, this is what responses typically look like and you can already see that the format is very structured. And that is why computers can easily work with it.
APIs at colabel
Our core software is built as an API. What you can see as a registered user is just the frontend but that is a separate application which makes it easier for people to navigate the functionality. But all it does is take user input, make requests to the API and look nice.
One of the benefits of that architecture is that we can also offer that API to others. That allows us to build integrations to other systems – like Zapier, Dropbox, etc. – and it can also be used by you or your developers directly.
Once you have trained your custom model, you will be able to see the API documentation that has been fully customized to you. It has a pre-configured POST request through which you can make all kinds of predictions. As a response, you will get a neatly formatted JSON file that always returns a response in the same format again.
Before we finish off, I want to restate again that you don't need to set up this API in any programming language. You can go alternative ways similar to the example we gave above. Happy requesting!