Not just backend developers—frontend developers should also have a solid understanding of HTTP methods.

And I’m sure you understand it will. But if not, here is a refresher for the most common HTTP methods.

1. GET: is the method used to retrieve data from the server.
2. POST: is how you send data to create resources.
3. PUT: is used to update or create a resource.
4. DELETE: removes a resource from the server.
5. PATCH: makes partial updates to an existing resource.

While they are doing great for their purpose, they have some more power, which is not very common.

Let’s see what are those:

Fact #1: GET Can Include a Body (But It’s Rarely Used)

GET requests usually don’t have a body, but they technically can.

You must be wondering why someone will send a body in GET; for that purpose, we already have POST. Yeah, you're right, but there are some cases where it can be useful. For example, in the case of Long URLs. You might need some parameters that can’t be sent in the URL due to its length restriction. In that case, sending in the body in JSON format can be useful. But it’s always better to use other methods like POST when you need to send data.

GET is flexible, but using a body is uncommon for good reason.

Fact #2: POST is Not Always About Creating Resources

While POST is known for creating new resources, it is also used for complex queries.

There are several use cases where the APIs need to filter the data based on several conditions. That condition can result in complex queries that can’t be sent in URLs due to their length restriction. In that case, POST might be a better choice than GET, as it can carry more data in the request body.

So, POST is versatile beyond just creating resources.

Fact #3: PUT vs PATCH: More Than Just Syntax

PUT replaces the entire resource, while PATCH makes partial updates.

If you use PUT to update a user profile, you must send the whole resource, even if only one field changes. Otherwise, all other details will be lost. In this case, PATCH is more efficient when only a small part of the data needs updating.

Remember, PATCH is your go-to for small, efficient updates.

Fact #4: DELETE Can Return a Body

It’s not common, but DELETE requests can return a response body.

After the DELETE requests are successful, it returns the confirmation that the resource was removed. But you can design your APIs in such a way that they can return the deleted resource’s details in the response. You may ask what the use of it is. They can be useful if you want to log in or display confirmation of the deleted data.

Well, DELETE isn’t just for removing—it can provide useful feedback, too.

Fact #5: Safe and Idempotent Aren’t the Same

Methods like GET are both safe and idempotent, but these terms mean different things.

A safe method doesn’t change the server’s state, while an idempotent method guarantees that repeating the request has the same effect every time. For example, DELETE is idempotent but not safe since it changes the server state by removing a resource.

~

Now, you may ask me, what is the point of knowing these lesser-known facts?

If you know these, the chances of unexpected behaviour in your APIs will be less.

I hope these lesser-known details will help you design and work with APIs more effectively. Let me know what other facts you know. Happy coding.

If you have enjoyed reading this, follow me on Twitter/X to read more.