Skip to main content
RESTful Principles
CHAPTER 06 Beginner

HTTP Methods Explained

Updated: May 13, 2026
5 min read

# CHAPTER 6

HTTP Methods Explained

1. Introduction

In the previous chapter, we learned that the URL dictates *what* resource we are interacting with. But how does the server know *what action* we want to perform on that resource? This is where HTTP Methods (often called HTTP Verbs) come into play. In Chapter 6, we will break down the fundamental HTTP methods, explain when to use each one, and show how they directly map to standard database operations.

2. Learning Objectives

By the end of this chapter, you will be able to:
  • Understand the 5 primary HTTP methods used in REST APIs.
  • Map HTTP methods to CRUD (Create, Read, Update, Delete) operations.
  • Explain the technical difference between PUT and PATCH.
  • Understand what the OPTIONS method is and why browsers use it.
  • Implement standard request routing based on the HTTP method.

3. Beginner-Friendly Explanation

Imagine a simple file folder in your physical filing cabinet.
  • GET is opening the folder and reading a piece of paper. (You aren't changing the paper, just looking).
  • POST is writing a brand-new piece of paper and dropping it into the folder.
  • PUT is taking an existing piece of paper, throwing it away, and replacing it with a newly written version that has the same title.
  • PATCH is taking a pencil, erasing one specific sentence on a paper, and rewriting just that sentence.
  • DELETE is taking the paper out of the folder and putting it in the shredder.

4. Real-World Examples

  • GET: Refreshing your Twitter feed to see new tweets.
  • POST: Pressing the "Publish" button on a new WordPress blog post.
  • PUT: Uploading a new profile picture that completely replaces your old one.
  • PATCH: Going to your account settings and changing only your "Phone Number" while leaving everything else exactly as it is.
  • DELETE: Clicking the trash can icon next to an email.

5. Detailed Code Examples

Here is how you handle different HTTP methods in a raw PHP API endpoint.
php
123456789101112131415161718192021222324252627282930 
<?php
$method = $_SERVER[&#039;REQUEST_METHOD'];

switch ($method) {
    case &#039;GET':
        // Code to fetch data from the database
        echo json_encode(["message" => "Fetching data"]);
        break;
    case &#039;POST':
        // Code to insert new data
        echo json_encode(["message" => "Creating new record"]);
        break;
    case &#039;PUT':
        // Code to completely replace data
        echo json_encode(["message" => "Replacing record completely"]);
        break;
    case &#039;PATCH':
        // Code to partially update data
        echo json_encode(["message" => "Updating record partially"]);
        break;
    case &#039;DELETE':
        // Code to delete data
        echo json_encode(["message" => "Deleting record"]);
        break;
    default:
        http_response_code(405);
        echo json_encode(["error" => "Method not allowed"]);
        break;
}
?>

6. Request/Response Examples

Let's look at the difference between PUT and PATCH payloads.

PUT Request (Complete Replacement):

http
12345678910 
PUT /users/5 HTTP/1.1
Host: api.example.com
Content-Type: application/json

{
  "first_name": "Jane",
  "last_name": "Doe",
  "email": "jane@doe.com",
  "age": 25
}

PATCH Request (Partial Update):

http
1234567 
PATCH /users/5 HTTP/1.1
Host: api.example.com
Content-Type: application/json

{
  "age": 26
}

7. HTTP Examples

The OPTIONS method is a special method used primarily by web browsers. Before a browser sends a POST or PUT request across different domains (CORS), it sends an OPTIONS request first. The server responds, telling the browser, "Yes, you are allowed to send a POST request here."
http
123 
OPTIONS /users HTTP/1.1
Host: api.example.com
Origin: https://mywebsite.com

8. JSON Examples

When building a robust API, returning the HTTP method in the response can help with debugging during the early development phase.
json
12345678 
{
  "debug_info": {
    "method_received": "DELETE",
    "resource_target": "users",
    "resource_id": 88
  },
  "success": true
}

9. Best Practices

  • Safety: GET and OPTIONS methods are considered "Safe." They should *never* modify database records. If your GET request deletes something, you have designed it incorrectly.
  • Idempotency: PUT and DELETE are "Idempotent." This means if a client accidentally sends the exact same DELETE request 5 times, the end result is the same (the resource is gone). POST is *not* idempotent. Sending the same POST 5 times will create 5 duplicate records.

10. Common Mistakes

  • Using GET for everything: Beginners often create URLs like GET /deleteItem?id=5. This is highly dangerous because search engine bots (like Googlebot) crawl GET links. The bot could accidentally delete your entire database by just "visiting" those links!
  • Using POST for updates: While POST *can* update data technically, you should use PUT or PATCH to adhere to REST standards and communicate your intent to other developers.

11. Mini Exercises

  1. 1. Match the SQL command to the HTTP Method: INSERT INTO
*(Answer: POST)*
  1. 2. Match the SQL command to the HTTP Method: SELECT * FROM
*(Answer: GET)*

12. Coding Challenges

Challenge 1: Write a PHP switch statement (like the example in Section 5) but add logic to extract JSON from php://input if the method is POST, PUT, or PATCH.

13. MCQs with Answers

Question 1

Which HTTP method is specifically designed for a partial update of a resource?

Question 2

Which HTTP methods are considered idempotent?

Question 3

What is the primary purpose of the OPTIONS method?

14. Interview Questions

  • Q: Explain the exact difference between PUT and PATCH. Provide a scenario for each.
  • Q: What does it mean for an HTTP method to be "Idempotent"?
  • Q: Why is it considered dangerous to use a GET request to delete or modify data?

15. FAQs

Q: My HTML form only supports GET and POST. How do I use PUT or DELETE? A: Standard HTML <form> tags do indeed only support GET and POST. In web applications, we usually send PUT or DELETE via JavaScript (AJAX/Fetch API). Some frameworks (like Laravel) fake it by using a POST request with a hidden input field like name="_method" value="DELETE".

Q: Do I have to support PATCH? A: No. Many APIs just use PUT for all updates, even partial ones, as it's easier to implement. However, if you want a strictly RESTful and highly optimized API, differentiating between PUT and PATCH is best practice.

16. Summary

In Chapter 6, we mapped the core actions of an API to standard HTTP methods. GET is for reading data safely. POST is for creating new resources. PUT is for replacing resources entirely, while PATCH is for precision updates. DELETE removes resources. Finally, we learned that adhering to these methods protects our applications from unintended data modifications and standardizes communication.

17. Next Chapter Recommendation

We know how to ask the server to do something, but how does the server tell us if the action was successful or if it failed? Proceed to Chapter 7: HTTP Status Codes to decode the numbers that servers use to communicate success and failure.

Finish this Chapter

Save your progress on your learning path and prepare for coding interview challenges.

Previous Chapter Resources and Endpoints
Next Chapter HTTP Status Codes

Discussion

Join the discussion

Log in or create a free account to participate.

Sort: ·

Explore More

📖 Related Tutorials 4

❓ Related Quizzes 5