Python x Django developer
APIs are less like USB ports or fire hoses than they are as a person at a help desk in a foreign country. An API will not give you all of a program’s information or code (like a fire hose), because what would stop you from replicating the entire code base?
Instead, an API provides you with data its programmers have made available to outside users. Even so, you have to know the language and ask the right questions to do anything with this data.
Computers make a lot of things easier, especially tasks that involve collecting and sorting through tons of data. Let’s say you wanted to know how many times a particular business partner submitted invoices to your company. You could feasibly go into your company’s invoice records, scan the“ from” data input, and print each invoice individually for your audit.
On the other hand, if all invoices were uploaded to a central database, you could write a simple program that accesses that database and finds all the instances of the partner’s name. This would take much less time and be much more accurate.
To use an analogy here, we’ll compare this to ordering a drink at a bar.
When you step up to the bar, you’re given a menu with several drinks listed. To look at this as an API, there’s an existing convention you can follow (i.e. the menu) to state your order and obtain a drink.
The menu, as it’s presented to you, is the interface. All the drinks listed on the menu are what the bartender has agreed to serve. When you ask for a certain drink on the menu, you receive it. But if you ask for something off the menu, such as a vodka martini instead of a gin martini, the bartender can’t provide it because it’s not something they agreed to serve.
Let’s say you want that gin martini delivered to your home. You call a delivery service and you order a martini that appears on the menu. When you order it, someone will tell the bartender your order, the bartender will make the martini and then someone will deliver it to your home. This is an example of an additional service (delivery) built on an “API” (the menu).
To relate this to the software, an API can help one application retrieve specific types of data from another. If the API doesn’t support certain types of data, it won’t be able to facilitate the retrieval of that “off-menu” data.
Okay, so an API is how two computers talk to each other.
The server has the data and sets the language, while the client uses that language to ask for information from the server (FYI, servers do not send data without a client requesting data, but developers have found some ways around this with webhooks). APIs can do anything!
Well, not so fast. The language and syntax of APIs severely limit their
abilities. There are four types of actions an API can take:
When you combine the endpoints with these actions, you can search or update any available information over an API. You’ll need to check the API
documentation to find out how to code these actions, as they’re all
While we’re talking about language and syntax, let’s cover the ways you can request a server:
HTTP: Hypertext transfer protocol. This is how you got to our site in the first place; by typing a URL in the search bar in your browser. This is a really easy way to access data, but it won’t come back to you in a pretty format if you request a lot of information. We’ll go into this further in just a second.
Text formats: XML, JSON. These are the main languages for accessing data over an API. When you receive your data, you will need to wade through the XML or JSON code to understand what the server gave you.
Many of the API uses you’ll see in your daily business lives move information from one program to similar form fields in another program. This is especially useful when you’re trying to share information that you would otherwise have to enter repeatedly; e.g. sharing leads between your marketing automation platform and your CRM.
The uses and examples we’ll list here are much more basic and pull much less data than what your standard API is good for. But they’ll give you a good idea of the steps in the API process.
Most APIs require an API key. Once you find an API you want to play with,
look in the documentation for access requirements. Most APIs will ask you to complete an identity verification, like signing in with your Google account. You’ll get a unique string of letters and numbers to use when accessing the API, instead of just adding your email and password every time (which isn’t very secure; for more information on authorizations and verifications, read this).
The easiest way to start using an API is by finding an HTTP client online, like REST-Client, Postman, or Paw. This ready-made (and often free) tools help you structure your requests to access existing APIs with the API key you received. You’ll still need to know some of the syntaxes from the documentation, but there is very little coding knowledge required.
The next best way to pull data from an API is by building a URL from the existing API documentation. This YouTube video explains how to pull location data from Google Maps via API, and then use those coordinates to find nearby photos on Instagram.
Overall, an API request doesn’t look that much different from a normal browser URL, but the returned data will be in a form that’s easy for computers to read.
An API is useful for pulling specific information from another program. If you know how to read the documentation and write the requests, you can get lots of great data back, but it may be overwhelming to parse all of this. That’s where developers come in. They can build programs that display data directly in an app or browser window in an easily consumable format. So then, see you next time techie and happy learning!
Previously published here.
Create your free account to unlock your custom reading experience.