Clearing the Air on APIs
I’ll admit that in my crash course on programming I jumped right into using Ruby on Rails as an API with the handy command line shorthand:
rails new my_api — apiI coded away without giving too much thought on what an API is or how it works on a high level. In fact, I went on to code a couple more projects with API’s and couldn’t always remember what the initials of API even meant. In documentation and articles, API gets thrown around so much that it distances itself from being an “Application Programming Interface” to being just a concept.
For me, that concept entailed using Rails as an API for the backend of a project because it has less files than a straight Ruby project. In the backend, it was useful for seeds, a database and models.
Later, the concept expanded to third-party applications that could be integrated into other projects. These are very general concepts and I, of course, want a deeper understanding so I can expand my thinking of these API’s.
What is an Application?
First, there are computer software programs (aka desktop applications) such as the web browser (Google Chrome, Safari, Microsoft Edge etc.), Microsoft Word or Adobe Photoshop. Basically, any program on the computer that has a specific function and is not apart of the operating system.
Next, there are mobile applications (or apps for short) that are meant for mobile devices. It’s everything from your texting app to Google Maps app and even to the alarm clock app.
Finally, there are web applications that are accessed via a web browser to perform specific tasks over the internet. Usually, these web apps live on a remote server. If you’re a developer working on the web app, you’ll probably have it stored locally.
Some of these web applications even have a desktop (or even mobile) app that you can download. A couple examples I can think of are: Slack, Zoom and Dropbox. With these, I can always access them through the browser and log into my account but the downloaded desktop versions sort of give me direct access to the server.
What is an API?
It’s the software in the middle that allows two applications to talk to each other. The API takes requests (probably in the form of a button or maybe a form with data) and tells the system/server of the other application what to do before returning the response.
Petr Gazarov, of freeCodeCamp, made an excellent example involving an airline website(s) and a travel service like Expedia that compiles info from multiple airlines. The airline has direct access to its own database, meanwhile, Expedia needs to interact with the airlines’ API in order to get information on flights from that database.
“[E]very time you visit a page on the Web, you interact with some remote server’s API. An API isn’t the same as the remote server — rather it is the part of the server that receives requests and sends responses.” — Gazarov
APIs streamline the interaction between applications, data and devices.
What is the difference between an Application and an API?
This caused me the most confusion. Applications are built for desktop, mobile/tablet and/or web to do a specific thing. Instead of trying to build EVERYTHING you, or the user, will want or need, you can just take advantage of another pre-built application. And, in order to interact with this other application, by sending requests and receiving responses, you will need to implement the API that will communicate between these two applications.
How does an API work?
On the most basic level, API’s differ primarily in “the format of the request and the response.”
HTML/JS responses can change what is displayed.
Data in a JSON format can be returned to be displayed or be available for further actions in the program.
Benefits
Security — info on your device (phone or computer) is never fully exposed to the server & the server is never fully exposed to your device
=> each only shares what is necessary (the request and the response)
Designed For (Easy) Use — documented/versioned to be used by developers
Standardized — monitored for performance and scale; developer friendly HTTP and REST
All-In-One — users can complete actions/send requests all from one website
=> they don’t leave
Microservices
Many times an application will be spread across several servers that interact with each other through APIs. Sending and receiving requests and responses to each other. Microservices is another term I’ve been seeing a lot lately and it’s basically the “servers that perform helper functions for the main application server”.
I hope this exploration of applications and APIs has clarified a few things for you as it has for me. Definitely, still a lot more to explore and be aware of about this crucial component of apps that we use everyday. Until the next dive into tech, thanks for reading!
