Difference Between HTTP Requests

All of us, use HTTP Requests every day while developing applications, websites, servers, even when we are surveying between different websites when we open a new website and the data of the website begin to load!

But what are they actually? How they differ from each other?

HTTP ( [H]yper[Text] [T]ransfer [P]rotocol ) Request is like a transfer line between client and server. When you write google.com and press the Enter button, it is actually calling a GET HTTP-Request for surveying inside the Google website. Also while opening a website like Amazon, we receive the data by HTTP-Request which brings data from the server to our clients. As a developer, we are using them as our APIs. While we send data by Request Body, we send some parameters by Request Params and etc.

From the first days of developing, we have learned to use different HTTP Request this way :

- POST: for [C]reating new objects

-GET: for [R]eading objects

-PUT or PATCH: for [U]pdating objects

-DELETE: for [D]eleting objects

As it is obvious, these upper-case letters are creating a familiar word in our mind: CRUD!

But why we use POST Request for creating objects? Why we do not send -everything through GET-Request and Parameters? While we can send our body data through both POST-Requests and PUT-Requests, what are the differences? Is sending data through body secure and nobody can see them through explorer?

Let’s have a look at it.

First of all, a common question is always present during this subject. While the developer is developing the service layer at the server, how could different HTTP Request types affect our logic?

The answer is, while we are talking about different kinds of HTTP Request and their features, we are talking about the standards of them. The PUT-Request is for updating data in many scenarios, but for sure the developer can develop the way that data could be deleted too! If you are a developer, just think about it. Isn’t it possible? For sure it is!

So read the article just as the standards of using different HTTP Requests.

Before reading the article let’s define the meaning of safe method and Idempotent method:

An HTTP method is safe if it doesn’t alter the state of the server. In other words, a method is safe if it leads to a read-only operation.

An HTTP method is idempotent if an identical request can be made once or several times in a row with the same effect while leaving the server in the same state. In other words, an idempotent method should not have any side-effects (except for keeping statistics).

Let’s start with GET-Request features:

GET-Request will request for a representation of one ( or some ) present data. Requests using the GET method could not include the request body. They can only include request parameters.

• GET-Request is very easy to be bookmarked in the browser.
• The length of a GET-Request is limited to 255 characters.
• Sending data is only possible while attached to the URL through the browser's URL bar while using GET-Request.
• While using GET-Request the data can be stored easily.
• GET-Request is often cacheable.
• GET-Request only supports the string data type.
• GET-Request is safe.
• GET-Request is idempotent.

Now Let’s see POST-Request features:

POST-Request sends data to the server by request body. The type of the body is indicated by the Content-type header. It is often used for storing some new data in the server including JSON, image, video and etc.

• POST-Request sends data by request body and query strings.
• Passed data by request body with POST-Request is not visible in the URL.
• POST-Requests will not be saved in the browser's history.
• The length of a POST-Request has no limitations.
• POST-Request can not be bookmarked.
• POST-Request helps clients pass sensitive and confidential information like login details to the server.
• POST-Request is hardly cacheable.
• POST-Request is not idempotent.
• POST-Request is not safe.
• POST-Request supports string, numeric, binary and etc.
• POST-Request has lower performance in comparison with GET-Request; Since it has to include the request body to the request and this operation spends time.

SO, Now let’s compare POST-Request and GET-Request. For this part, we start with we advantages and disadvantages of GET-Request.

Advantages of GET-Request:

• Retrieve the information identified by request URI.
• Can be viewed in the browser's history.
• Enables to save the result of a HTML form.
• Easily can be used to request required data.

Disadvantages of GET-Request:

• Can not be used for data like image, videos and etc.
• It will be used only for retrieving data.
• Can not be used for sensitive data.
• Its length is limited.
• While using GET-Request, all the data will be appended to the URL.
• It can be easily bookmarked with all its data.

Now let’s take a look at the advantages and disadvantages of POST-Request.

Advantages of POST-Request:

• Helps you determine the resource’s URI.
• Sends the req to accept the entity as a new resource.
• Sends user-generated data to the webserver.
• It is very useful when you just want to send a body and do not know anything about its structure.
• It is very useful when you need the webserver to control the URL generation of your resource.
• It is secure as its data does not remain in history.
• Effortlessly transmit a large amount of data using POST-Request.
• While using the request body, the data will be more private to common users.
• Sends binary as well as ASCII data.

Disadvantages of POST-Request:

• You can not save data in the URL.
• Data will not be saved in the browser.
• It is not compatible with many firewall setups.
• It takes a lot of time for updating large binary files.

Now Let’s see PUT-Request features:

PUT-Request is used for creating a new resource or replacing one present resource with the request payload. It has some differences with POST-Request which we will see in the next part but just like POST, it has a request body too which helps us to send our data to the server.

• PUT-Request is idempotent.
• PUT-Request helps you store supplied entity undersupplied URI.
• PUT-Request creates the sent data on the sent URI or updates the existed data on that URI.
• Creating data with PUT-Request is easy.
• The client does not have to check whether submit button is clicked once or more than once.
• PUT-Request is cacheable.
• PUT-Request is not safe.
• PUT-Request is not allowed in HTML forms.
• The client needs to call the exact URI while using PUT-Request; For example, sending PUT-Request to /questions is not correct since the exact URI is not called. Calling /questions/{question-id} is the correct form.

SO, Now let’s compare POST-Request and PUT-Request.

• PUT-Request is idempotent while POST-Request is not.
• PUT-Request modifies a single resource that is already part of resource collections, but OST-Request will add a child resource under the collection.
• PUT-Request is cacheable but POST-Request is not.
• While using PUT-Request, the client decides which URI resource to be updated or created but while using POST-Request it is all to the webserver.
• While using PUT-Request the API is always like /entities/{entity-id} but while using POST-Request it is always like /entities.

Now Let’s see PATCH-Request features:

PATCH-Request is used to apply some partial modifications to a resource.

• PATCH-Request is not necessarily idempotent contrasting to PUT-Request which is always idempotent.
• PATCH-Request is used to update some parts of the data in contrast to PUT-Request which removes the existing one and replaces the requested one on that URI.
• PATCH-Request has a body.
• PATCH-Request is not safe.
• PATCH-Request is not cacheable.
• PATCH-Request is allowed in HTML forms.

And for the last one, Let’s see DELETE-Request features:

DELETE-Request deletes the specified resource.

• DELETE-Request may have a body.
• It may cause some servers to reject your request but you can still send the ID using URL parameters.
• DELETE-Request is not safe.
• DELETE-Request is idempotent.
• DELETE-Request is not cacheable.

So like you have read, we can develop our server in a way that we can use the DELETE method instead of GET method too! But just as lots of standards in developing applications and websites, let’s pay attention to this standard too. It will make our APIs more readable and it makes the way more clear for the next developers too!

Always remember, you are not going to develop one project for your whole life. Let’s develop it the way next developers could understand it without calling you 100 times! :D