It is quite inevitable to use the wrong HTTP verb when developing your API, especially as a beginner. I once faced the same contingency when I was at the beginning phase of developing APIs. I knew what each verb meant, but I ignorantly misused them.

After several projects and tutorials, I realized that I was following the wrong approach. With more understanding, I was able to practice using the right HTTP verb for the right purpose. That is what I will be showing you in this post.

Before we get started, I believe we should cover as much as possible. Let's get to know what HTTP verbs are and why you should use them correctly.

What are HTTP verbs?

HTTP stands for “Hypertext Transfer Protocol,” and it is considered by many—myself included—to be the life of the web. When it comes to transferring documents or making a request, HTTP is the backbone. In simple terms, it is a protocol responsible for transferring documents over the web.

Easy right? Let me guess: you have probably never heard of protocols. If you have, I think you should go to the next heading, but if you haven't, “protocols” are a determined set of rules that govern the exchange of information across the web.

Why should I use the right HTTP verb?

As a developer of any stack, it is important to get a hang of the tools you use and be effective with them. Therefore, if you are developing APIs, you need to know how HTTP works. It gives your API an edge and ensures proper usage of third-party developers.

A little need to know

It is important to understand two keywords when it comes to using HTTP verbs efficiently, and those are “safe” and “idempotent.”

Safe deals with read-only, which means you can make requests to an endpoint and not worry about any data being updated or destroyed.

Idempotent, on the other hand, means you can make multiple requests to an endpoint without changing anything or getting a different result.

Generally speaking, all safe methods are idempotent, but not all idempotent methods are safe. It's a bit of a conundrum if I must say so, but you are in the right place. You will get the idea as you read more.

Let's get right to it: HTTP Verbs

Additional knowledge is that—after all, you are reading this to learn—HTTP verbs give the server instructions on what to do with the data sent through the URL. Now, let's talk about a few briefly.

GET

You should use get only when you wish to read data, not store or update. Among others, the GET is the simplest verb. Conclusively, now that we know GET is only used for reading and the same data is always returned, we can say that they are safe and idempotent.

POST

Whenever you try to make a POST request, everyone is expecting that you are trying to store something. That is trying to add a new resource to the database. The POST method is said to be neither safe nor idempotent because a new resource is being created, and making two requests to the same endpoint will yield different results.

PUT

You may have come to the thought, “How then do I update?” This is where the PUT request comes in. It is often used in the context of updating resources. PUT can also be used to create new resources, but the client will have to define the ID. Trust me, it gets more complicated, so I won't advise that. What I recommend is to only use this verb when you want to update. It is not a safe operation because it makes changes on the server side, but guess what? It is an idempotent operation.

PATCH

Here is where it gets interesting, PATCH is also used to update resources, but unlike PUT, it updates just the changed data and not the entire resource. It is neither safe nor idempotent. In the real world, PATCH is rarely used.

DELETE

The way it sounds is how it operates. You can simply use DELETE to destroy redundant resources from the database. It is certainly not a safe operation, but some say it is idempotent and some say it is not.

Cessation

Well, if you got to this extent, you have certainly gained one or two points. Another piece of advice I would like to give is that using the right HTTP verbs will make your API more fault-tolerant. Your API will also be more methodical in its operations.

Here's a pro tip: the GET operation should never be used for creating or updating.

That's a wrap! I'll see you again in subsequent posts.