HTTP Methods

Introduction

HTTP methods, also called HTTP verbs, define the action a client wants the server to perform on a resource. When a client sends an API request, the method is one of the first pieces of information the server reads. It tells the server whether the client wants to retrieve data, create a record, replace a resource, update selected fields, delete something, inspect endpoint capabilities, or retrieve only response metadata. Without methods, every HTTP request would look similar and servers would need unclear custom rules to understand intent.

For REST APIs, HTTP methods are especially important because they connect the API design to predictable web standards. A product list should usually be retrieved with GET. A new order is commonly created with POST. A full customer profile replacement may use PUT. A small update such as changing a phone number may use PATCH. Removing a resource may use DELETE. Browser capability checks and CORS preflight requests may use OPTIONS. Header-only checks may use HEAD.

For API testers, understanding HTTP methods improves both test design and defect analysis. If an API uses GET to delete data, that is a design smell. If a create API returns the wrong status code, the response may confuse clients. If a PATCH request replaces an entire object, the implementation may not match its intended method. If DELETE behaves differently on repeat calls, idempotency expectations may need review. HTTP methods give testers a standard vocabulary for checking whether API behavior is consistent, safe, and understandable.

In simple terms, HTTP methods are standardized verbs that specify what action the client wants the server to perform on a resource.

What Are HTTP Methods?

HTTP methods are request types defined by the HTTP protocol. Each method has a specific meaning. The method appears at the beginning of the request line, before the path and HTTP version. In a request such as GET /users/101 HTTP/1.1, GET is the method, /users/101 is the resource path, and HTTP/1.1 is the protocol version.

Methods help separate the resource from the action. The path identifies what the client is interacting with, while the method explains what the client wants to do. For example, GET /users/101 means retrieve user 101. DELETE /users/101 means remove user 101. The path is the same, but the method changes the operation.

This separation makes APIs easier to understand. Instead of creating endpoint names such as /getUser, /deleteUser, and /updateUser, a RESTful API can use resource-oriented paths and methods. This leads to cleaner contracts, better documentation, and more predictable testing.

Common HTTP Methods and CRUD Mapping

The most common HTTP methods used in API testing are GET, POST, PUT, PATCH, DELETE, OPTIONS, and HEAD. The first five are often mapped to CRUD operations: create, read, update, and delete.

CRUD mapping is a helpful learning model, but real APIs sometimes use methods more flexibly. For example, POST /login does not create a user record; it submits credentials and starts an authentication flow. POST /reports may create a background job. POST /payments/refund may represent an action. The important point is that the method should communicate intent clearly and consistently.

GET Method

The GET method retrieves data from the server. It should not modify server-side data. When a client sends a GET request, it is asking to read a resource or collection. Common examples include retrieving products, users, orders, account balances, employee details, search results, or configuration data.

GET /users/101 HTTP/1.1
Host: api.example.com

A typical response may be:

{
  "id": 101,
  "name": "John"
}

GET is considered a safe method because it should not change server state. It is also idempotent, which means sending the same GET request multiple times should have the same effect as sending it once. The returned data may change if the underlying resource changes, but the act of making the request should not cause modification.

GET requests are often cacheable. Browsers, CDNs, proxies, and clients may cache responses depending on headers such as Cache-Control, ETag, and Last-Modified. This makes GET useful for improving performance, but testers should understand caching behavior when validating fresh data.

API testing for GET should verify the status code, response body, headers, content type, response schema, data accuracy, sorting, filtering, pagination, response time, and behavior when the resource does not exist. It should also confirm that a read request does not modify data. If a GET call creates records, updates timestamps incorrectly, or triggers destructive behavior, the API design needs review.

POST Method

The POST method is commonly used to create a new resource or submit data for processing. A client sends a request body, and the server processes it. In a REST API, POST /users may create a new user. POST /orders may create a new order. POST /payments may initiate a payment. POST /login may authenticate a user and return a token.

POST /users HTTP/1.1
Content-Type: application/json

{
  "name": "John",
  "email": "john@example.com"
}

A successful create response often returns 201 Created and the new resource details:

HTTP/1.1 201 Created

{
  "id": 101,
  "name": "John"
}

POST is not normally idempotent. If the same create request is submitted twice, it may create two resources. If the same payment request is submitted twice without idempotency protection, it may create duplicate charges. This is why API design often uses idempotency keys for sensitive operations such as payments and order submissions.

Testing POST requires more than checking response status. Testers should verify that data is stored correctly, required fields are validated, invalid values are rejected, duplicates are handled, database state is correct, response fields are accurate, and sensitive information is not exposed. They should also test repeated submission behavior, especially for payment, order, booking, and registration flows.

PUT Method

The PUT method is used to replace an existing resource. In many API designs, PUT expects the client to send the complete representation of the resource. Fields omitted from the request may be overwritten, cleared, reset to defaults, or rejected depending on the API's implementation. Because of this, clients should understand the contract before using PUT.

Suppose the current user resource is:

{
  "id": 101,
  "name": "John",
  "city": "Chicago"
}

A full replacement request may be:

PUT /users/101
Content-Type: application/json

{
  "id": 101,
  "name": "David",
  "city": "New York"
}

After this request, the complete user representation should match the submitted object according to the API contract. If city was omitted and the API treats PUT as full replacement, city might be cleared. This is one of the practical differences between PUT and PATCH.

PUT is usually idempotent. Sending the same PUT request once or multiple times should result in the same final resource state. This does not mean every response must be identical, but the final effect should be the same. API testers should verify idempotency, full replacement behavior, required field handling, missing field behavior, status codes, and database state after updates.

PATCH Method

The PATCH method updates only specific fields of a resource. It is used for partial updates. Instead of sending the full object, the client sends only the fields that should change. Fields not included in the request should remain unchanged unless the API contract says otherwise.

Suppose the current user resource is:

{
  "id": 101,
  "name": "John",
  "city": "Chicago"
}

A partial update request may be:

PATCH /users/101
Content-Type: application/json

{
  "city": "Boston"
}

The expected result is:

{
  "id": 101,
  "name": "John",
  "city": "Boston"
}

Only city changed. The name remained unchanged. This makes PATCH efficient for large resources and useful when clients need to update only one or two fields. It also reduces the chance that a client accidentally overwrites data it did not intend to change.

PATCH may or may not be idempotent depending on implementation. A request that sets city to Boston is idempotent because repeating it leaves the same final state. A request that increments a counter may not be idempotent because repeating it changes the value repeatedly. Testers should understand the specific API behavior rather than assuming every PATCH works the same way.

Testing PATCH should verify that only specified fields change, unspecified fields remain intact, invalid fields are rejected, partial validation works correctly, response body reflects updated state, and audit fields or timestamps behave as expected.

PUT vs PATCH

PUT and PATCH are often confused because both update resources. The difference is scope. PUT is generally used for full replacement, while PATCH is used for partial update. If the client wants to replace the whole user profile, PUT may be appropriate. If the client wants to change only the phone number, PATCH is usually more suitable.

In testing, the practical question is what happens to omitted fields. If a PUT request omits a field, does the API clear it, preserve it, or reject the request? If a PATCH request omits a field, it should usually preserve it. These differences should be documented and tested.

DELETE Method

The DELETE method removes a resource or marks it as deleted depending on the API design. A request may look like this:

DELETE /users/101

A successful response may be 204 No Content when there is no response body, or 200 OK when the API returns a confirmation body. Some APIs implement soft delete, where the record remains in the database but is marked inactive. Others physically remove the record.

DELETE is considered idempotent in HTTP semantics. Deleting the same resource multiple times should have the same final effect: the resource is gone or unavailable. The first call may return 204, while a repeated call may return 404 depending on API design, but the final state remains the same.

Testing DELETE should verify that the resource is removed or deactivated correctly, database state matches the contract, subsequent GET requests behave correctly, repeated delete requests are handled predictably, unauthorized users cannot delete, and dependent records are handled safely. Delete operations should be tested carefully because they can affect data integrity.

OPTIONS Method

The OPTIONS method asks the server which communication options are supported for a resource. It can return allowed methods and other capability information. A request may look like this:

OPTIONS /users

The response may include:

Allow: GET, POST, PUT, DELETE

OPTIONS is especially important for browser-based clients because browsers use CORS preflight requests. Before sending certain cross-origin requests, the browser sends an OPTIONS request to check whether the actual request is allowed. The server must return appropriate CORS headers, or the browser will block the request even if the backend API itself could process it.

API testers should verify allowed methods, CORS headers, supported operations, and behavior for unsupported endpoints. Ignoring OPTIONS can create issues for frontend applications that call APIs from browsers.

HEAD Method

The HEAD method works like GET, but the server returns only headers and no response body. It is used to retrieve metadata about a resource. A request may look like this:

HEAD /users/101

A response may include:

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

No response body should be returned. This makes HEAD useful for checking whether a resource exists, validating metadata, inspecting content type or size, and supporting caching behavior without downloading the full response.

Testing HEAD should verify status code, headers, content type, content length where applicable, cache headers, and absence of response body. A common mistake is returning a full body for HEAD, which violates the expected behavior.

Safe and Unsafe Methods

A safe method is one that should not change server data. GET, HEAD, and OPTIONS are considered safe. They are meant for retrieval, metadata, or capability discovery. Calling them should not create, update, or delete business resources.

Safe does not mean nothing at all happens. A server may log the request, update analytics, or refresh cache metadata. The key idea is that the requested business resource should not be changed. If a GET request updates an order status or deletes a record, it violates safe-method expectations.

Idempotent and Non-Idempotent Methods

Idempotency means performing the same request multiple times has the same final effect as performing it once. GET, PUT, DELETE, HEAD, and OPTIONS are generally considered idempotent. POST is generally not idempotent. PATCH depends on implementation.

Idempotency matters for retries. Networks fail. Clients timeout. Gateways retry. Users double-click buttons. If retrying a request creates duplicate orders or duplicate payments, the API can cause serious business problems. For non-idempotent operations, APIs often use idempotency keys, unique request ids, or duplicate-detection rules.

API testers should validate repeated request behavior. A repeated PUT should leave the same final resource state. A repeated DELETE should not recreate data or cause uncontrolled errors. A repeated POST should be tested according to business rules, especially for payments and order creation.

Real-World Examples

In an e-commerce system, GET /products may display product listings. POST /products may allow an admin to add a new product. PUT /products/100 may replace complete product details. PATCH /products/100 may update only the price. DELETE /products/100 may remove or deactivate a product.

In banking, GET /accounts/123/balance may read balance, POST /accounts may open an account, PUT /customers/100 may replace customer details, PATCH /customers/100/mobile may change a mobile number, and DELETE /beneficiaries/50 may remove a saved beneficiary. These method choices make the API easier to reason about.

API Testing Checklist for HTTP Methods

For GET, verify that correct data is returned, no data is modified, pagination and filtering work, response time is acceptable, and missing resources return the expected status. For POST, verify that the resource is created, database state is updated, mandatory fields are validated, duplicate submission is handled, and the response body contains useful created-resource information.

For PUT, verify that the complete resource is replaced, omitted-field behavior matches documentation, idempotency is preserved, invalid full objects are rejected, and the response status is correct. For PATCH, verify that only requested fields are updated, unchanged fields remain intact, invalid fields are rejected, and partial validation is correct.

For DELETE, verify that the resource is removed or marked inactive, dependent data is handled safely, subsequent GET behaves correctly, repeated delete behavior is predictable, and unauthorized deletion is blocked. For OPTIONS, verify allowed methods and CORS headers. For HEAD, verify headers and confirm that no response body is returned.

Status Codes by HTTP Method

HTTP methods and status codes should work together. The method explains what the client requested, while the status code explains what happened. If these two do not align, clients and testers receive confusing signals. For example, a successful resource creation through POST commonly returns 201 Created. A successful delete that returns no body commonly returns 204 No Content. A successful read through GET commonly returns 200 OK.

For GET, testers usually expect 200 OK when data is found, 404 Not Found when a specific resource does not exist, and sometimes 204 No Content or an empty collection when a collection query has no results. The expected behavior should be documented because an empty collection and a missing resource are not always the same thing.

For POST, testers often expect 201 Created when a new resource is created. If the operation is an action rather than resource creation, such as login or search submission, 200 OK may be valid. If validation fails, 400 Bad Request or a similar documented validation status should be returned. If authentication is missing, 401 Unauthorized is more appropriate than a generic server error.

For PUT and PATCH, successful updates commonly return 200 OK with the updated resource, or 204 No Content when no response body is returned. If the target resource does not exist, the API may return 404 Not Found. Some APIs allow PUT to create a resource at a known URL, but that behavior must be clearly documented and tested.

For DELETE, successful deletion commonly returns 204 No Content. If the API returns a confirmation body, 200 OK may be used. A repeated delete may return 404 Not Found if the resource no longer exists, or it may return 204 No Content again. Both patterns can be acceptable if the final state is correct and the contract is clear.

Security Considerations for HTTP Methods

HTTP methods also affect security testing. Sensitive operations should not be exposed through methods that are treated as safe. A delete, update, payment, or account-change operation should not be performed through GET. Browsers, crawlers, caches, prefetch mechanisms, monitoring tools, and users may repeat GET requests under the assumption that they do not modify data. If a GET request changes server state, accidental or unauthorized actions become more likely.

Authorization should be validated for every method independently. A user who can read a resource with GET should not automatically be allowed to update it with PUT, partially update it with PATCH, or delete it with DELETE. Access control should match the operation. Testers should check method-level permissions, not only endpoint-level permissions.

Method tampering is an important negative test. If a client changes GET /users/101 to DELETE /users/101, the server should enforce authorization and method rules. If an endpoint supports only GET, unsupported methods should return controlled responses such as 405 Method Not Allowed. The response should not expose stack traces or internal routing errors.

For browser-based clients, OPTIONS and CORS behavior are part of security. The server should allow only expected origins, headers, and methods. Overly broad CORS settings can expose APIs to unnecessary risk. Testers should verify that unsafe methods are not accidentally allowed from untrusted origins.

Method Selection in Real API Design

Choosing the right method is not only a theoretical REST topic. It affects how clients behave, how caches work, how retries are handled, how logs are interpreted, and how testers design automation. A well-designed API makes the intended operation obvious. When the method and resource path are clear, the API contract becomes easier to learn.

For example, GET /orders/1001 clearly means read order 1001. PATCH /orders/1001 with a body containing {"status":"cancelled"} clearly means update only the status. POST /orders/1001/cancel may also be acceptable if cancellation is treated as a business action with side effects beyond a simple field update. The best design depends on the domain, but the method should still communicate intent.

Some operations do not fit cleanly into basic CRUD. Login, logout, password reset, report generation, payment capture, refund processing, bulk import, and workflow approval are action-oriented. Many APIs use POST for these operations because they submit a command to the server and may cause state changes. That is acceptable when the action is named clearly and the behavior is documented.

API testers should evaluate method selection from the consumer's perspective. Is the method predictable? Does it match the operation? Does it create risks for caching or retries? Are status codes consistent with the method? Does documentation explain any non-standard behavior? These questions help testers find design issues before clients depend on the API.

Handling Duplicate Requests and Retries

Duplicate requests happen in real systems. A user may double-click a submit button. A mobile app may retry after a network timeout. A gateway may retry a failed upstream request. A client may not receive the response even though the server completed the operation. HTTP method semantics help teams decide what should happen when the same request is repeated.

For idempotent methods such as GET, PUT, and DELETE, retries are usually safer because the final state should remain the same. A repeated PUT replacing a profile with the same data should not create duplicate profiles. A repeated DELETE should not create new side effects beyond ensuring the resource is no longer available.

POST is riskier because it may create new records each time. For example, two identical POST /orders requests may create two orders unless the API protects against duplicates. Payment APIs commonly use idempotency keys so the server can recognize that a retry belongs to the same original operation. The server can then return the original result instead of creating another payment.

API testers should include duplicate-request scenarios for create and action endpoints. The test should answer practical questions: does the API create duplicates, reject duplicates, return the existing result, or require an idempotency key? For critical workflows, this behavior should be explicit in both documentation and tests.

Documentation Expectations for HTTP Methods

Good API documentation should clearly state which method each endpoint supports and what that method means for the resource. It should include sample requests, sample responses, request body requirements, response status codes, validation errors, authorization requirements, and idempotency expectations. Without this information, consumers may use the endpoint incorrectly and testers may make wrong assumptions.

For PUT and PATCH, documentation should be very specific about omitted fields. If PUT requires the full object, the docs should say so. If PATCH supports only selected fields, the docs should list them. If some fields are read-only and cannot be changed, the docs should identify them. This prevents accidental data loss and makes automation more precise.

For DELETE, documentation should explain whether deletion is hard delete or soft delete, what status code is returned, what happens on repeated deletion, and whether dependent resources are affected. For OPTIONS, docs should explain CORS behavior where browser clients are supported. For HEAD, docs should identify which headers are expected to match GET.

Testers should compare API behavior against documentation. If an endpoint documents PATCH as partial update but actually clears omitted fields, that is a defect. If a create endpoint documents 201 Created but always returns 200 OK, the contract and implementation are inconsistent. Documentation accuracy is part of API quality.

Best Practices

Use the appropriate HTTP method for each operation. Clear method usage makes APIs easier to consume, document, and test. Do not use GET for operations that modify data. Such design can create security, caching, and accidental execution problems because clients and crawlers may treat GET as safe.

Use POST for resource creation or non-idempotent actions. For sensitive operations such as payments, bookings, and order placement, consider idempotency keys to protect against duplicate submissions. Use PUT for complete replacement when the client provides the full resource. Use PATCH for partial updates where only selected fields should change.

Return appropriate HTTP status codes. A successful creation commonly returns 201 Created. A successful deletion with no body commonly returns 204 No Content. Invalid input should not return 500 Internal Server Error. Status codes should help clients understand the result.

Keep API behavior consistent with HTTP semantics. If a method behaves in a surprising way, document it clearly or reconsider the design. Consistency reduces bugs and makes automation more reliable.

Common Mistakes

One common mistake is using GET to delete or update data. This violates safe-method expectations and can create accidental changes through browser prefetching, crawlers, caching, or repeated requests. Another mistake is using POST for every operation. While this may seem simple, it hides intent and makes the API less RESTful and harder to test.

Confusing PUT and PATCH is also common. If an endpoint uses PUT but behaves like partial update, clients may misunderstand omitted-field behavior. If an endpoint uses PATCH but replaces the entire resource, data loss may occur. Documentation and tests should make update semantics clear.

Returning a response body for HEAD is another mistake. HEAD should return headers only. Ignoring OPTIONS can break browser-based clients because CORS preflight checks may fail. Using incorrect status codes is also common, such as returning 200 OK when a new resource should return 201 Created or returning 500 for validation errors.

Interview-Ready Explanation

HTTP methods are standardized request types that define the action a client wants to perform on a resource. The most common methods are GET, POST, PUT, PATCH, DELETE, OPTIONS, and HEAD. GET retrieves data, POST creates or submits data, PUT replaces a resource, PATCH partially updates a resource, DELETE removes a resource, OPTIONS discovers supported operations, and HEAD retrieves headers without a body.

A strong answer should also mention safe and idempotent behavior. GET, HEAD, and OPTIONS are safe because they should not change server data. GET, PUT, DELETE, HEAD, and OPTIONS are generally idempotent. POST is generally not idempotent, and PATCH depends on implementation.

For API testing, HTTP methods are important because the tester must verify that each endpoint uses the correct method, returns the correct status code, follows the expected CRUD behavior, handles repeated requests properly, validates inputs correctly, and preserves data integrity.

Key Takeaway

HTTP methods are the action words of API communication. They tell the server what the client wants to do with a resource. Correct method usage makes APIs predictable, readable, testable, and aligned with web standards. Incorrect method usage creates confusion, caching risks, duplicate-processing problems, and poor client behavior.

For testers, methods provide a practical checklist. A GET should retrieve without modifying. A POST should create or submit data and handle duplicates safely. A PUT should replace a full resource. A PATCH should update selected fields. A DELETE should remove or deactivate correctly. OPTIONS should communicate allowed operations, and HEAD should return headers only.

The simplest summary is this: choose the method that matches the business operation, implement it consistently, and test both its normal behavior and its edge cases.