HTTP Methods Explained: GET, POST, PUT, DELETE and Beyond

HTTP methods (also called HTTP verbs) define the action to be performed on a resource identified by a URL. They are the foundation of RESTful API документацию design and are essential for correct client-server communication. Understanding HTTP methods is crucial for building, consuming, and monitoring web APIs.

Overview of HTTP Methods

Safe means the method does not modify server state. Idempotent means calling the method multiple times produces the same result as calling it once. *PATCH can be idempotent depending on the implementation.

GET — Retrieve Data

GET requests retrieve data from the server without modifying anything. They are the most common HTTP method, used for loading web pages, fetching API data, and downloading files.

GET /api/v1/users/42 HTTP/1.1
Host: api.example.com
Accept: application/json
Authorization: Bearer eyJhbGci...

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: max-age=60

{"id": 42, "name": "Alice", "email": "alice@example.com"}

Key rules for GET:

• Never use GET to modify data — this violates HTTP semantics and creates security risks
• GET requests should be cacheable and bookmarkable
• Parameters go in the URL query string, not the request body
• URLs have practical length limits (2048 chars in many browsers) — do not encode large data in query strings

POST — Create or Trigger

POST sends data to the server to create a new resource or trigger a server-side action. It is not idempotent — sending the same POST twice may create two resources.

POST /api/v1/users HTTP/1.1
Host: api.example.com
Content-Type: application/json

{"name": "Bob", "email": "bob@example.com"}

HTTP/1.1 201 Created
Location: /api/v1/users/43
Content-Type: application/json

{"id": 43, "name": "Bob", "email": "bob@example.com"}

Common use cases:

• Creating new resources (users, orders, posts)
• Submitting forms
• Uploading files
• Triggering processes (sending emails, running reports)
• Any operation that is not idempotent

PUT — Replace Entirely

PUT replaces the entire resource at the given URL with the data in the request body. If the resource does not exist, PUT may create it (implementation-dependent). PUT is idempotent — sending the same PUT multiple times has the same effect as sending it once.

PUT /api/v1/users/43 HTTP/1.1
Content-Type: application/json

{"id": 43, "name": "Bob Smith", "email": "bob.smith@example.com", "role": "admin"}

HTTP/1.1 200 OK

Important: PUT replaces the entire resource. If you omit a field, it should be removed or set to its default value. This is different from PATCH, which updates only specified fields.

PATCH — Partial Update

PATCH applies partial modifications to a resource. Only the fields included in the request body are updated; all other fields remain unchanged.

PATCH /api/v1/users/43 HTTP/1.1
Content-Type: application/json

{"role": "admin"}

HTTP/1.1 200 OK
Content-Type: application/json

{"id": 43, "name": "Bob", "email": "bob@example.com", "role": "admin"}

DELETE — Remove a Resource

DELETE removes the resource at the given URL. It is idempotent — deleting an already-deleted resource should return success (or 404), not an error.

DELETE /api/v1/users/43 HTTP/1.1
Authorization: Bearer eyJhbGci...

HTTP/1.1 204 No Content

HEAD — Metadata Only

HEAD is identical to GET except the server must not return a response body. It is used to check resource existence, validate caches, or retrieve headers without downloading the full content.

HEAD /large-file.zip HTTP/1.1
Host: cdn.example.com

HTTP/1.1 200 OK
Content-Length: 524288000
Content-Type: application/zip
Last-Modified: Mon, 15 Jan 2024 10:30:00 GMT
ETag: "abc123"

Use cases for HEAD:

• Checking if a URL is alive (uptime monitoring)
• Getting file size before downloading
• Validating cache freshness with If-None-Match or If-Modified-Since
• Checking redirect chains without downloading content

OPTIONS — Communication Capabilities

OPTIONS describes the communication options available for a resource. It is most commonly seen in CORS preflight requests:

OPTIONS /api/v1/users HTTP/1.1
Host: api.example.com
Origin: https://app.example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: Content-Type, Authorization

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Max-Age: 86400

PUT vs PATCH: When to Use Which

HTTP Methods in Monitoring

For web monitoring, HTTP methods have specific implications:

• HEAD for uptime checks — use HEAD instead of GET to minimize bandwidth and avoid side effects
• GET for content verification — when you need to validate response content, not just availability
• OPTIONS for CORS testing — verify that cross-origin policies are correctly configured
• Response codes matter — a 405 Method Not Allowed indicates the endpoint exists but does not support the method used

Best Practices for API Design

• Use the correct method for each operation — do not use POST for everything
• Return appropriate status codes: 200 (OK), 201 (Created), 204 (No Content), 404 (Not Found), 405 (Method Not Allowed)
• Make idempotent methods truly idempotent — retrying a PUT or DELETE should be safe
• Include Location header in 201 responses to point to the created resource
• Support HEAD for any GET endpoint — it comes for free in most web frameworks
• Document allowed methods with the Allow header in 405 responses

Summary

HTTP methods provide clear semantics for client-server interactions. Using them correctly — GET for reading, POST for creating, PUT for replacing, PATCH for partial updates, DELETE for removing, HEAD for metadata, and OPTIONS for capabilities — leads to predictable, cacheable, and maintainable APIs. Understanding their safety and idempotency properties is essential for building reliable web services and implementing effective monitoring strategies.