In this article, we’ll discuss the API/HTTP request methods and how to use them. We’ll look at the reasons for using HTTP request methods such as GET, POST, PUT, and others. The topics we’ll cover in this post are:
HTTP Protocol
Client-Server Architecture
APIs
What is HTTP?
HTTP is a protocol, or a defined set of rules, for accessing resources on the web. Resources can be anything from HTML files to database data, photos, text, etc. These resources are made available to us through an API, and we make requests to these APIs through the HTTP protocol. API stands for Application Programming Interface. It is the mechanism that allows developers to request resources.
Client-Server Architecture
To understand HTTP methods, it’s important to cover the concept of client/server architecture. This architecture describes how all web applications work and the rules for how they communicate.
A client application is the part with which the user interacts and displays the content. On the other hand, a server application sends the content or resource to your client application. The latter runs in the backend and is constantly listening and waiting for requests. The main reason for this separation is to protect sensitive information and efficiency. We can consider the entire client application to be downloaded in the browser, and all data can be accessed by anyone who accesses your website. This architecture helps protect things like API keys, personal data, etc. Now, modern tools like Next.js and Netlify allow developers to run server code in the same application as their client application, without the need for a dedicated server application.
Client-Server Communication
Client and server applications communicate by sending individual messages as needed, rather than a continuous stream of communication. These communications are almost always initiated by clients in the form of requests. These requests are handled by the server application, which returns a response with the requested resource, among other things.
Why We Need a Server-Client Architecture
Let’s say you’re building a weather web app, for example. The weather app the user will interact with is the client app: it has buttons, a search bar, and displays data like the city name, current temperature, AQI, etc.
This weather app wouldn’t have each city and its weather information hardcoded directly into it. This would make the app bloated and slow, take forever to manually research and add to a database, and be a pain to update every day.
Instead, the app can access weather data by city using the Weather Web API. Your app would collect your user’s location and then make a request to the server saying, “Hey, send me the weather information for this specific city.”
Depending on what you want to achieve, you would use the various request methods available. The server returns a response with the weather information and a few other things, depending on how the API is written. It can also return things like a timestamp, the region in which this city is located, etc.
Your client application communicates with a server application running somewhere, whose sole job is to continuously listen for a request to that address. When it receives a request, it works to fulfill it, either by reading from a database, another API, a local file, or by performing a programmatic calculation based on the data you pass to it.
The Anatomy of an HTTP Request
An HTTP request must have the following:
An HTTP method (such as GET)
A host URL (such as https://api.spotify.com/)
A path to an endpoint (such as v1/artists/{id}/related-artists)
A request can also optionally have:
Body
Headers
Query strings
HTTP version
The Anatomy of an HTTP Response
The response must have the following:
Protocol version (such as HTTP/1.1)
Status code (such as 200)
Status text (OK)
Headers
A response can also optionally have:
Body
Explanation of HTTP Methods
Now that we know what HTTP is and why it’s used, let’s talk about the different methods available to us.
In the weather app example above, we wanted to retrieve weather information about a city. But what if we wanted to send weather information about a city?
In real life, you probably wouldn’t have permission to alter someone else’s data, but let’s imagine we’re collaborators on a meta-application.