Understanding HTTP Methods

Introduction

In our last lesson, we broke down the URL and understood that it's the unique address for a resource on the web. We now know where to send a request. But what do we want to do once we get there? Do we want to read data, add new data, change existing data, or delete it?

That's where HTTP methods come in. They are the "verbs" of the web, specifying the action you want to perform on the resource at a given URL.

Today, we will focus on the four most common and essential HTTP methods. By the end of this lesson, you will be able to distinguish between GET, POST, PUT, and DELETE, and understand when to use each one. This is a cornerstone concept for interacting with any API.

The Four Core Actions: CRUD

In the world of software and databases, there are four fundamental actions one can perform on data. This is known as CRUD:

• Create: Add a new piece of data.
• Read: Retrieve or view existing data.
• Update: Modify existing data.
• Delete: Remove existing data.

Almost everything you do in a web application, from posting a photo to updating your profile, falls into one of these four categories. HTTP methods provide a standard way for a client to tell a server which of these actions it wants to perform.

Each CRUD operation maps directly to one of the main HTTP methods.

Let's dive into what each method does.

The Four Main HTTP Methods

We'll now explore each method with a practical analogy. The following video from IBM Technology does an excellent job of explaining this using an ice cream shop API.

As you saw in the video, each method has a distinct purpose. Let's summarize and solidify those ideas.

1. GET: Reading Data

• Purpose: To retrieve or "read" a resource.
• CRUD equivalent: Read.
• How it works: You send a request to an endpoint (a URL path), and the server sends the data back. For example, GET /products would fetch a list of products, and GET /products/42 would fetch the single product with ID 42.
• Key Characteristic: A GET request should never change data on the server. It's for reading only.

2. POST: Creating Data

• Purpose: To create a new resource on the server.
• CRUD equivalent: Create.
• How it works: You send data (e.g., the details of a new user or a new blog post) in the body of the request to an endpoint like POST /users. The server then creates a new entry.
• Key Characteristic: Sending the same POST request multiple times will typically create multiple new resources.

3. PUT: Updating Data

• Purpose: To update an existing resource by completely replacing it.
• CRUD equivalent: Update.
• How it works: You send the complete, updated representation of a resource to a specific endpoint, like PUT /products/42. The server replaces the old version of product 42 with the new data you sent.
• Key Characteristic: Sending the same PUT request multiple times has the same effect as sending it once—the resource is simply updated to the same state each time.

4. DELETE: Removing Data

• Purpose: To delete a specific resource.
• CRUD equivalent: Delete.
• How it works: You send a request to a specific resource's endpoint, such as DELETE /products/42, to instruct the server to remove it.
• Key Characteristic: Like PUT, a DELETE request is "final." Sending it again for the same resource has no additional effect, as the resource is already gone.

Here's another visual example showing how these methods might be used to manage job postings in an API.

Deeper Dive: Safe and Idempotent Methods

To truly master these methods, it's helpful to understand two important concepts: safety and idempotence. These terms describe the expected behavior of HTTP requests.

• Safe: A method is "safe" if it does not alter the state of the server. You can make a safe request as many times as you want without any side effects.
• Idempotent: A method is "idempotent" if making the same request multiple times produces the same result as making it just once.

The following video from Telusko offers a clear explanation of these concepts.

Let's summarize this in a table:

Understanding this table is key. For example, knowing that POST is not idempotent tells you to be careful not to submit a form twice, or you might create two identical orders!

A Simple Analogy to Make It Stick

Technical definitions are useful, but a good analogy can make a concept unforgettable. The following reading uses a simple restaurant scenario to explain the four methods.

To recap that excellent analogy:

• GET is like asking, "Can I see the menu?" (You're just requesting information).
• POST is like saying, "I'd like to place a new order." (You're creating something new).
• PUT is like telling the waiter, "Actually, change my entire order to this instead." (You're replacing an existing order).
• DELETE is like saying, "Please cancel my order." (You're removing it).

Conclusion

You've now learned the four fundamental "verbs" of the web. By understanding the specific purpose of GET, POST, PUT, and DELETE, you're one major step closer to fluently communicating with APIs.

Key Takeaways:

• HTTP methods correspond to CRUD operations: Create (POST), Read (GET), Update (PUT), and Delete (DELETE).
• GET retrieves data and is safe (it doesn't change anything).
• POST creates new data and is not idempotent (repeating it creates more data).
• PUT updates/replaces existing data and is idempotent.
• DELETE removes data and is also idempotent.
• Using the correct method makes your intentions clear and your interactions with an API predictable and reliable.

You now know where to send a request (the URL) and what action you want to perform (the HTTP method). But how does the server tell you if your request was successful, or if something went wrong?

In our next lesson, we'll answer that by exploring HTTP status codes, the server's way of responding to your requests.