HTTP-request methods: GET vs POST vs PUT and others

Radzivon Alkhovik
Low-code automation enthusiast, Latenode partner
A low-code platform blending no-code simplicity with full-code power
Get started free
Table of contents

Say no to chaotic work. Automate your tasks now.

In this article we’ll break down the most popular HTTP-request methods for REST API, discover what’s the difference between Post, Get, Put, Delete and Patch methods and how to use them all!

What is HTTP-request?

If API is the way applications talk to each other, then HTTP-requests are the sentences. And just like sentences, we can divide them into groups depending on the aim of the sentence, do we want to ask something, or deliver a message.

Illustration of What is HTTP-request

So, in the REST API, HTTP-requests are divided into methods depending on their purpose.

Here are the most usable methods:

  • GET
  • POST
  • PUT

Let’s find out what these methods are step-by-step!

GET method

Understanding HTTP GET Requests

HTTP GET requests are designed for retrieving information from a specified resource on the internet without altering the data. This method is safe because it doesn't change the data's state. It's essential to grasp this concept to distinguish what is a get request from other types of HTTP requests, like POST or PUT, which are used to modify or add data on the server.

GET requests should consistently return the same results if made multiple times, unless the data has been updated by a POST or PUT request. This characteristic is a fundamental part of understanding the difference between GET and POST requests, as well as the role of PUT requests in web development.

Response Codes for GET Requests

When a GET request is made, the server responds with different status codes depending on the outcome:

  • A 200 (OK) status code means the request was successful, and the server is returning the information requested, which is a direct example of a successful get request.
  • A 404 (NOT FOUND) status code indicates that the requested resource cannot be found on the server, highlighting a key get request outcome.
  • A 400 (BAD REQUEST) status code is returned if the request was improperly formed, pointing to the importance of correctly structuring HTTP requests.

These responses are crucial for developers to understand how their requests are being processed and are part of learning about HTTP methods, including GET, POST, and PUT.

Practical Examples of GET Requests

Let's look at some practical examples to understand how GET requests are used:

  • Retrieving a list of user accounts: HTTP GET
  • Fetching a subset of user accounts with specific parameters: HTTP GET
  • Accessing details for a specific user account: HTTP GET
  • Getting detailed information for a user's address: HTTP GET

POST method

HTTP POST requests are essential in web development for creating new subordinate resources, such as adding a file to a directory or a new row to a database table. This method is especially relevant when discussing what is a post request, and how to send a post request.

In the context of RESTful services, POST is primarily used to introduce a new entity to a collection of resources, a process central to understanding the difference between get and post, as well as get post put interactions.

It's important to note that responses to POST methods aren't cacheable unless specified by Cache-Control or Expires header fields, distinguishing POST from get requests in terms of cache behavior.

Unlike GET requests, POST is neither safe nor idempotent. This means executing identical post requests consecutively will result in creating multiple unique resources, highlighting the practical implications of post and get, post and put, as well as the broader request method landscape.

What are POST API Response Codes

When a POST operation successfully generates a new resource on the server, the appropriate response is a 201 (Created) status code. This response should detail the request's outcome, reference the new resource, and include a Location header, providing a real-world application of post request examples and HTTP post response insights.

There are instances where a POST action doesn't lead to a uniquely identifiable resource. In such cases, the server may return a 200 (OK) or 204 (No Content) status, reflecting on the nuanced differences in post vs put request, get vs post, and the overall request methods framework.

Demonstrating POST Requests with Examples

To illustrate, consider these example URIs that embody post to url and POST method practices:

  • Creating a new user profile: HTTP POST
  • Adding specific details to a user profile: HTTP POST

PUT method

Use PUT APIs primarily to update an existing resource (if the resource does not exist, then API may decide to create a new resource or not).

If the request passes through a cache and the Request-URI identifies one or more currently cached entities, those entries SHOULD be treated as stale. Responses to PUT method are not cacheable.

3.1. PUT API Response Codes

HTTP PUT requests are crucial for tweaking existing online content or adding new items if they don't already exist. This method shines when you're updating details on a webpage or submitting new entries, straddling the line between what is a put request and put vs post decisions. It's a fundamental tool in the developer's kit, especially when debating post and put usage or exploring the nuances of put and post actions. 

If a PUT request passes through a digital storage spot (cache) and finds that it's addressing content that's already stored, it flags that content as old news. What's interesting here is that the outcomes of these PUT actions don't hang around in the cache, setting them apart from how get and post requests are handled. This distinction is pivotal in the difference between get and post, as well as understanding the strategic deployment of get post put operations in web development.

Key Points About PUT Responses

  • If PUT makes something new, the web server will tell you with a 201 (Created) message. This clears up some of the fog around http post response and when to post to url.
  • Changing something that's already there will get you a nod with a 200 (OK) or a simple 204 (No Content) heads-up. It’s a concise way to distinguish between put method actions and put and post debates.

Examples of PUT in Action

Let's look at PUT doing its thing:

  • To update user info, you’d go with: HTTP PUT
  • Changing account details? Try: HTTP PUT

DELETE method

How DELETE Works with Web APIs

The DELETE function in web APIs is straightforward: it gets rid of resources you point to with their web addresses (URIs).

Here’s something interesting about DELETE: it’s supposed to work the same way every time. If you delete something, it should stay deleted. But, some people argue that since the item isn't there anymore, trying to delete it again doesn't really do the same thing, which could make you think twice about whether DELETE always works the same way. It's a topic some people like to discuss and see differently.

If your DELETE request goes through a place where web info is saved (like a cache) and it finds stuff under the same address, that stuff should be marked as old. And just so you know, the answers you get back from a DELETE don't get saved in this cache.

What Happens After You DELETE

What happens after you hit DELETE can vary a bit:

  • You might get a 200 (OK) status back if the server tells you how the delete went.
  • If the server is still thinking about it and has your delete request waiting in line, you'll see a 202 (Accepted) status.
  • Sometimes, the server has done what you asked but doesn’t give you any details back. In that case, you’ll see a 204 (No Content) status.

If you try to delete the same thing twice, the second time won’t really do anything new because the item was already deleted the first time. So, you’ll probably get a 404 (NOT FOUND) because, in the server's eyes, there’s nothing there to delete anymore.

Example URIs with Updated Links

  • To delete a user profile: HTTP DELETE
  • To remove specific account details for a user: HTTP DELETE

PATCH method

HTTP PATCH requests are used to update part of a resource.

Like PATCH, PUT requests can also change a resource. But here's a clearer way to think about it: use PATCH when you want to update just a piece of the resource, and go for PUT when you're planning to replace the whole thing.

Keep in mind, though, that using PATCH in your app might run into some issues:

Not all web browsers, servers, and frameworks fully support PATCH. For example, Internet Explorer 8, PHP, Tomcat, Django, and many others either don't support PATCH at all or don't handle it properly.

How to use GET/POST/PUT/DELETE methods with no code?

The answer is clear: use no-code/low-code tools for it! Latenode is a perfect choice, because it has an HTTP-request node where you can use any of these methods to integrate with ANY app that has an API.

You can use this template that uses just some of HTTP-request abilities,


Now that you're equipped with knowledge about HTTP request methods like GET, POST, PUT, DELETE, and PATCH, you're prepared to take your understanding of APIs to the next level.

However, our exploration doesn't conclude here. We invite you to delve into our final article - REST API Headers & Body, to further refine your mastery of APIs.

Should you have questions or desire further discussion, we welcome you to join our Discord community. There, we're committed to sharing insights and providing support as you continue your journey through the world of automation.

Optimize your Business Process on Latenode – the best automation platform for you

Related articles:

Related Blogs

Backed by