Types of HTTP Method That Every Developer(even wannabe) Should Know

Casual Chitchat(Optional):

Note: Do Skip Casual Chitchat Block if you only looking to learn only technical things and don't want to read random chit-chat.

It is always hard to write blogs in the middle when you are watching web series (You know what I mean). Currently watching the walking dead I must admit it is a stupid show and zombies are not that horrific. it is easy to kill zombies when they are this slow assuming of course. Just after a couple of seasons, I liked one character too much named “Negan”. I just loved the way he talks & acts as Most BAD-ASS. it has become one of my best villains. I liked him too much that I straight mentioned him in my blogs(even when it is a technical blog).

Introduction(Back to Work):

We will be discussing 7 types of HTTP methods -:
1. GET
2. POST
3. PUT
4. DELETE
5. PATCH
6. OPTIONS
7. HEAD

Wait a minute why do we need a different method and how it is useful for us(i am just a normal coder eating pudding pie & writing buggy code)?

Data is always operated on the basis of CRUD(Create, Read, Update & Delete) Operation. the server should always know the intent of the operation. Application is exposed through API. all the code that you do working your ass off only makes meaning when you create API(Application Programming Interface) basically to expose the functionality to the outer world.
It hides all the internal detail of how code is doing things internally just exposed the functionality like pushing the button of lift in the mall it doesn’t tell how you are going upward or bottom(you don’t need to worry about that).

Basically different types of methods specify the API intent to the outer world and the server itself. it tells what operation API is meant to perform and must only be used for that operation.
Api meant to do create operation means it is going to create a new entity on the server. Api meant to do get operation means it is only going to retrieve data but will never going to change any existing data. So that’s why we used different HTTP methods to show the intent of the operation gonna be performed via request.

So it is a standard that everyone should follow while developing API & why follow the standard? To make it understandable for others you follow standards everywhere e.g. like talking a common language that everyone can understand(English, Hindi…etc), you walk with legs because that is a standard not with your hands. Standard ensures the best practices are being followed everywhere.

GET -

GET request is used to retrieve data from the server. its purpose is to only retrieve data nothing else. GET requests don’t affect the data state. we can call it any number of times but the result will be always the same. we can say that GET is idempotent.

What is idempotent?
idempotent means it doesn’t change the state of data(resource) irrespective of how many times it is called. Let’s take an example in a mathematical way.
check the example

f(x) = x * 1
f(f(f(f(f(x)))))..........

multiplication with 1 is always idempotent you can call it 10000 times but the result is always the same.

can you think of another example what about addition with 0

f(x) = x + 0
f(f(f(f(f(x)))))..........

this function is idempotent as it not changing the result irrespective of any number of times it is called.

Now think of GET request as same as this function means any number of times you call get request result will always going to be same. it never changed the data.

Let’s consider this API -

GET Request -  pass person id to retreive data for specific person
api/person/{id}/        
first time call - 
Response 
{
   "name" : "Mr. Donkey",
   "Age"  : 25
}
second time call -
Response 
{
   "name" : "Mr. Dumbo",
   "Age"  : 25
}
third time call -
Response 
{
   "name" : "Mr. hunky",
   "Age"  : 25
}

is the above GET request is idempotent?

If you look every time we make a request name attribute gets changed which means the GET request is wrong as it is not following the idempotency rule. it clearly changing the data in request this means the endpoint is poorly written and your boss might be thinking about why he hired you in the first place.

Let’s refactor this API —

GET Request -  pass person id to retreive data for specific person
api/person/{id}/
first time call -
Response 
{
   "name" : "Mr. Donkey",
   "Age"  : 25
}
second time call -
Response 
{
   "name" : "Mr. Donkey",
   "Age"  : 25
}
third time call -
Response 
{
   "name" : "Mr. Donkey",
   "Age"  : 25
} ......................................... result is still same

Now API shows idempotent behavior every time we make request response is still same. it is not changing with any number of calls it means API is only used to retrieve data nothing else. we have not used any logic to change the state of data only we are retrieving data.

POST-

POST is used to create resources on the server. it is only used as a create operation. POST request means it is going to create a new resource on the server it means if you are calling a request multiple times it ended up creating a new resource every time. it should be clear it doesn’t get used as an update operation. we can also say that POST is non-idempotent we get different results every time we make requests.
Let’s consider this mathematical operation —

f(x) = x + 2
f(f(f(f(f(f(f(x)))))))

it always makes different results it keeps on adding 2 to the result.
the same behavior you should expect with a POST request as it is non-idempotent & always leads to create a new different result.
Let’s check this demo POST API —

POST Request -  
api/person
body - {
   "name" : "Mr. Donkey",
   "age" : 25
}
Response -
Mr. Donkey created successfully with id 152

Here we are hitting API person endpoint means we are requesting to create a new person and in the body request, we are sending person detail.
The server creates a new person with a name & age. if you can see we have sent the id(152) in response unique identifier for a particular person as the name can be duplicated.

Let’s check POST API non-idempotent behaviour —

body - {
   "name" : "Mr. Donkey",
   "age" : 25
}
first time call - 
Response -
Mr. Donkey created successfully with id 152
second time call -
Response -
Mr. Donkey created successfully with id 153
third time call -
Response -
Mr. Donkey created successfully with id 154
fourth time call -
Response -
Mr. Donkey created successfully with id 155

Now we are requesting to create a new person every time with the same details. As POST is non-idempotent means it creates new resources every time & generates a different result.
So Mr. donkey has got created multiple times and every entity is different from other entities as their id is different. so you should recognize them as a different entity even when their details are the same. Be careful when you used POST API as it always changed the state of resources. its intent should be clearly defined & should always be used to create a new resource.

PUT-

PUT operation is used to update resources (data) on the server. it also used to create resources but only once if not exist and it should yield the same result every time means it is idempotent.
Put operation is not used for partial updates it means you need to send the whole entity that you want to update. this statement is confusing. let’s understand it with an example.

Check this entity:

Dog {
   name="Mr. Doggo",
   age=2,
   peeTime=1.00A.M,
   ownerName="Mr. Owner",
   breed="DouberMan"
}

suppose you want to update the name only then also you need to send the whole existing resource entity. so you need to send all fields with the updated values.

// only want to update name but have to send whole entity 
Dog {
   name="Mr. Butterbite",
   age=2,
   peeTime=1.00A.M,
   ownerName="Mr. Owner",
   breed="DouberMan"
}

This means Put Operation support full update, not partial update. like sending only the name in the request is a partial update.

You might be thinking PUT can also be used to create resources & POST is also doing the same thing what the hell this blog is trying to fool us?
So the main difference is PUT is always idempotent whereas POST is non-idempotent. so every time you make a PUT request result should always be the same. PUT can also be used to create something but it should be idempotent means every request should yield the same result and should not change the state of resources on the server. we will discuss it through an example

Check this simple PUT API call -

PUT Request -  
api/person/{id}                // pass existing person id to update
first time call -
body - {
   "name" : "Mr. Donkey",
   "age" : 25
}
Response -
Person updated successfully with id 152
second time call - 
body - {
   "name" : "Mr. Hunk",
   "age" : 25
}
Response -
Person updated successfully with id 152
third time call -
body - {
   "name" : "Mr. Bully",
   "age" : 25
}
Response -
Person updated successfully with id 152

In the above request, we are passing a person id that needs to be updated as a path variable and changing the name multiple times.
This request is idempotent because we are generating the same result and not affecting the state of data. every time we make a request name got updated by a new value but id always remains the same.
so basically each request is not creating a new resource with a different id just updating a name or age attribute every time with the new value.

DELETE-

As that name implies it is used to delete resources. everyone loves deleting things more than creation like all the ugly photos on the phone :).

When we want to delete resources(data) from the server we used delete API. can you think about what server needs to delete data? unique identifier for resources so basically we pass unique identifier for resources & server delete that particular resource.
it is not mandatory we need to pass unique identifiers we can also delete whole resources. but the point is whenever we delete anything from the server we use delete API.

Let’s check this simple delete API — 
DELETE Request — pass person id to delete data for specific person
api/person/{id}/
first time call -
api/person/152
response - 
person is deleted successfully
second time call -
api/person/153
response - 
person is deleted successfully
second time call -
api/person/154
response - 
person is deleted successfully

Delete request is idempotent means the result will always be the same and it doesn’t affect the state of resources.
its sole purpose is to delete data nothing else. if it is deleting data means every deleted resource has the same effect and it doesn’t affect the state of resources.
For the delete request, you just need to pass the identifier for the particular resources that you want to delete.
If you want to do a bulk delete let’s check this example -

Let’s check this simple delete API — 
DELETE Request — bulk delete all the person 
api/person/
response-
person is deleted successfully

here we are just pointing to a resource that we want to delete means requesting to delete all the people from the server.

PATCH-

PATCH is also used to update resources but it is different from PUT. PUT is used to update the whole resource entity whereas PATCH is used for the partial update.

simple words, in PUT you need to send the whole entity & it will overwrite the whole entity whereas PATCH is used to do partial updates. But why the hell do we need a partial update? we can just use PUT request
To save the bandwidth why do we need to send the whole data that we don’t want to update? we send only data that we want to update.

Let’s take an example to understand the concept-
suppose we want to update the Address of the person

PUT- /api/person/{id} // pass the id of person to update address
body- {
   "name": "Mr. FOO"
   "age": 24,
   "address": "Some Place to Live"
   "fatherName": "Definetly have some father",
   "gfName": "Not Possible"
}
PATCH - /api/person/{id}/address
body- {
   "address": "another place to live"
}

When we want to update the address of a person we need to send the whole entity object in a PUT request whereas in PATCH we only need to send attributes that we want to update. so PUT is used as a complete update whereas PATCH is used for partial updates(only the address or name).

Another difference is PATCH is non-idempotent whereas PUT is idempotent. if you think hard it will not be easy to digest how PATCH is non-idempotent? as it is also updating the resources same as PUT.
PATCH request is not only about updating the specific attribute it can contain a set of instructions to describe how the attribute can be updated to create a new version of the entity.
Simple words PATCH can contain a list of changes(instructions) to be applied while modifying resources so it can create a new version of resources.

Let’s take an example -

PATCH - /api/person/{id}/age
Request - {
  "age" : 24
} 
// server logic increment age by 2
age = age + 2
// now modify the age

The above example PATCH requests update age by adding 2 so PATCH request can have a list of instructions to be applied while modifying resources in other words it can create a new version of resources.
PATCH request you don’t know how the resources are modifying. maybe the age is multiples by 2 or divided by 2 whatever. this behavior makes PATCH a non-idempotent request it creates a new version of the resources. PATCH can be used both as idempotent & non-idempotent.

OPTIONS-

OPTIONS is used to check the communication method available for resources.
Let’s understand it with an example -

Api Resource - /api/dog

Now how do we know a particular resource (Dog) supports GET, POST, PUT, PATCH, OR DELETE requests?
Maybe we make a PUT request & we got a clumsy error PUT request was not available(method not found).

Let’s make options request -

OPTIONS - /api/dog
Response - 
200 OK
Allow: GET,POST,DELETE,OPTIONS

Now we know dog resources only support GET, POST, DELETE & OPTIONS. it doesn't support PUT & PATCH.

OPTIONS - /api/person
Response - 
200 OK
Allow: GET,POST,PUT,PATCH,DELETE,OPTIONS

basically, it sent a header in response with Allow attribute containing all the available methods for resources.

It is mostly used for browser preflight requests & CORS origin access. these topics not covering now because who wants to write long boring blogs. Use your google skills to learn about them if you don’t know it is a very important concept.

OPTIONS is an idempotent request it has nothing to do with data creation or update. it always returns the same response info about the resources.

HEAD-

HEAD is just GET request but only header & without a body in response.
HEAD is basically used to get meta-information about the resource to add performance. HEAD response only contains header & no body.

Let’s understand its use how it adds performance. consider this 100 MB file.

HEAD - /api/download/file
response -
HTTP/1.1 200 OK
Content-Length: 100000000  // 100 mb file

Now we already know the file size is large(100 MB) & we need to handle 100 MB files on the network if we make a GET request.

HEAD is also used to check the last modified time so we don’t need to use GET resources if we already did.

HEAD - /api/download/file
response -
HTTP/1.1 200 OK
Content-Length: 100000000  // 100 mb file
Last-Modified: Tue, 29 Nov 2021 23:38:37 GMT // last modified time

Now we can check what is last modified time of resources & only make a request when it is modified (what good to download 100 MB file again & again if it is not modified).

There are many use cases of HEAD just covering few basics(will be enough for now).

As HEAD only sends meta information it is idempotent as it doesn’t change the state of resources.

END-

it is time to say goodbye. we have covered the basics of the HTTP method that every developer should know. it is a very important topic and part of the developer's job. it leaves a very bad impression if you don’t use the method appropriately. like GET request creating entity & POST request retrieving entity. coworker will definitely going to judge you. the boss can go into an existential crisis. clients can cry loud & make the deal off. Every developer is expected to go deep dive into the HTTP methods concepts as it is part of their daily job.