SyntaxStudy
Sign Up
REST API GET, POST, PUT, PATCH, DELETE
REST API Beginner 1 min read

GET, POST, PUT, PATCH, DELETE

HTTP defines nine methods; REST APIs use five regularly. GET retrieves a resource and is safe (no side effects) and idempotent (repeated calls return the same result). POST creates a new resource and is neither safe nor idempotent. PUT replaces a resource completely and is idempotent; PATCH partially updates it and may or may not be idempotent depending on implementation. DELETE removes a resource and is idempotent—deleting the same resource twice should return 200 or 204 the first time and 404 on subsequent calls (or 204 again if you prefer). Using the correct method matters for caching, browser behaviour, and semantic clarity.
Example
# --- GET: read, safe, idempotent, cacheable ---
GET /users/42 HTTP/1.1
Host: api.example.com
Accept: application/json
# Response: 200 OK + user object

# --- POST: create, not safe, not idempotent ---
POST /users HTTP/1.1
Content-Type: application/json
{ "name": "Bob", "email": "bob@example.com" }
# Response: 201 Created
# Location: /users/101

# --- PUT: full replace, idempotent ---
PUT /users/42 HTTP/1.1
Content-Type: application/json
{ "name": "Alice Updated", "email": "alice@new.com", "role": "admin" }
# All fields must be supplied; missing fields are set to null
# Response: 200 OK + updated object  (or 204 No Content)

# --- PATCH: partial update ---
PATCH /users/42 HTTP/1.1
Content-Type: application/json
{ "email": "alice@newer.com" }
# Only the supplied fields change
# Response: 200 OK + updated object

# --- DELETE ---
DELETE /users/42 HTTP/1.1
# Response: 204 No Content  (no body)
# Second DELETE: 404 Not Found

# --- HEAD: like GET but no body (check existence/headers) ---
HEAD /users/42 HTTP/1.1
# Response: 200 OK, headers only

# --- OPTIONS: discover allowed methods (CORS preflight) ---
OPTIONS /users HTTP/1.1
# Access-Control-Allow-Methods: GET, POST, OPTIONS