HTTP Methods Overview0%
Status Codes

HTTP Methods Overview

Beginner12 min read•Updated: Jul 11, 2026
Study MaterialsCheatsheet

HTTP Methods: GET, POST, PUT, PATCH, DELETE

The HTTP protocol defines a set of request methods to indicate the desired action to be performed on a given resource. Designing professional REST APIs requires strict adherence to method semantics, idempotency, and safety.

1. HTTP Methods Comparison Matrix

MethodCRUD ActionSafe?Idempotent?Request Body Allowed?Standard Success Status
GETRead / RetrieveYesYesNo200 OK
POSTCreate / ActionNoNoYes201 Created
PUTReplace / OverwriteNoYesYes200 OK or 204 No Content
PATCHPartial UpdateNoNo (Technically)Yes200 OK
DELETEDestroy / RemoveNoYesOptional (Rare)204 No Content

2. Safe vs Idempotent Methods

  • Safe Methods: Calling the method never modifies server-side resource state. GET, HEAD, and OPTIONS are safe (read-only).
  • Idempotent Methods: Making the exact same request once produces the exact same server-side outcome as making it 100 times. GET, PUT, DELETE, HEAD, and OPTIONS are idempotent.
Output
Idempotence Example (PUT vs POST):
POST /orders/ ──► Executes 5 times ──► Creates 5 separate order records! (NOT IDEMPOTENT)
PUT /users/4/ ──► Executes 5 times ──► Replaces user 4 with identical data (IDEMPOTENT)
DELETE /orders/9 ──► Executes 5 times ──► Order 9 is gone after run 1; remaining runs do nothing (IDEMPOTENT)

3. The PUT vs PATCH Distinction

A frequent source of API design errors is confusing PUT and PATCH:

PUT (Full Resource Replacement):

PUT replaces the entire target resource representation. Any existing fields omitted from the payload are reset to default values or set to null!

JSON
// Original resource on server:
// { "id": 1, "name": "Alice", "role": "admin", "bio": "Senior Architect" }
 
// Client sends PUT with only name:
// PUT /users/1/ { "name": "Alicia" }
 
// Result on server:
// { "id": 1, "name": "Alicia", "role": null, "bio": null } <-- Omitted fields wiped!

PATCH (Partial Modification):

PATCH applies partial delta updates. Only the provided keys are mutated; unmentioned fields remain unchanged:

JSON
// Client sends PATCH:
// PATCH /users/1/ { "name": "Alicia" }
 
// Result on server:
// { "id": 1, "name": "Alicia", "role": "admin", "bio": "Senior Architect" } <-- Preserved!

4. Method Handling in Django REST Framework

DRF simplifies method routing in APIViews:

Python
from rest_framework.views import APIView
from rest_framework.response import Response
from rest_framework import status
 
class ProductAPIView(APIView):
def get(self, request, pk):
# Safe & Idempotent Read
return Response({"id": pk, "name": "Cloud Server"})
 
def put(self, request, pk):
# Complete overwrite
return Response({"status": "Product overwritten completely"})
 
def patch(self, request, pk):
# Partial update
return Response({"status": "Product attributes patched"})
 
def delete(self, request, pk):
# Idempotent deletion
return Response(status=status.HTTP_204_NO_CONTENT)
Interactive Quiz

Practice Quiz

Question 1
What does it mean for an HTTP method to be "idempotent"?
Question 2
What is the critical difference between PUT and PATCH?
Question 3
What standard HTTP status code should be returned upon successful creation of a resource via POST?
Question 4
Which of the following HTTP methods is considered "safe" (read-only)?
Question 5
What standard HTTP status code should a DELETE endpoint return when deletion succeeds and no response body is returned?
Next Lesson

Status Codes

Continue learning with hands-on practice, examples, and exercises in the upcoming topic.

Related Lessons

Previous LessonNext Lesson
REST PrinciplesStatus Codes

Practice Quiz

Test your understanding of this lesson with 5 questions. Each question has one correct answer.

PreviousNext
PrevNext