HTTP APIs rely on request methods such as GET, POST, PUT, and DELETE to signal whether a client is reading data, creating objects, updating state, or removing resources. Choosing the correct verb keeps application intent clear and allows infrastructure components to apply caching, routing, and security rules consistently.
cURL uses GET by default for HTTP and HTTPS URLs, switches to POST when body data is sent, and can override the method with the --request option. The selected verb becomes part of the HTTP request line, for example POST /items HTTP/1.1, so adjusting it is enough to exercise different behaviors against the same endpoint.
Incorrect verbs can cause subtle bugs, cached responses, or unintended data changes, especially when proxies or load balancers apply method-specific restrictions. Before sending state-changing calls, API documentation, authentication requirements, and idempotency guarantees must match the intended verb, and verbose output from cURL offers an immediate way to confirm that the correct method actually went on the wire.
Steps to specify the HTTP method in cURL:
- Open a terminal on any system where cURL is installed.
- Send a request without specifying a method to observe the default GET behavior.
$ curl --silent http://api.example.net/resource { "id": 123, "status": "ok" }Without additional method options, cURL sends a GET request for HTTP and HTTPS URLs.
- Override the default method with --request to send a POST request.
$ curl --silent --request POST "http://api.example.net/resource" { "id": 123, "status": "created" }Short form -X POST performs the same override but long options keep commands easier to read in shared examples.
- Attach form-style data with --data when the chosen method expects a request body.
$ curl --silent --request POST --data "field=value" "http://api.example.net/post" { "args": {}, "data": "field=value", ##### snipped ##### "method": "POST" }Using --data without --request already implies POST, so an explicit method is mainly useful for clarity or non-POST verbs that still send a body.
- Include a matching Content-Type header when sending JSON or other structured payloads.
$ curl --request PUT \ --header "Content-Type: application/json" \ --data '{"id":1,"status":"updated"}' \ "http://api.example.net/items/1" { "id": 1, "payload": "{\"id\":1,\"status\":\"updated\"}", "status": "updated" }Matching method, URL, and media type with API documentation avoids responses such as 400 Bad Request or 415 Unsupported Media Type.
- Use a safe method such as HEAD when only response headers and status information are required.
$ curl --silent --head --include "http://api.example.net/" HTTP/1.1 200 OK Server: sg-httpbin-lite/1.0 Python/3.12.3 Date: Sat, 10 Jan 2026 05:14:55 GMT Content-Length: 62 Content-Type: text/html ##### snipped #####
HEAD returns headers without a response body, which speeds up checks against large resources.
- Test API-specific verbs such as PATCH or OPTIONS by passing the verb name directly to --request.
$ curl --silent --request OPTIONS --include "http://api.example.net/items" HTTP/1.1 204 No Content Server: sg-httpbin-lite/1.0 Python/3.12.3 Date: Sat, 10 Jan 2026 05:14:55 GMT Allow: GET, POST, OPTIONS Content-Length: 0 Content-Type: text/plain; charset=utf-8 ##### snipped #####
Most APIs accept PATCH for partial updates and may advertise supported verbs in the Allow header or in separate documentation.
- Enable verbose output for a destructive method such as DELETE to confirm the request line and response status before relying on the result.
$ curl --request DELETE --verbose --output /dev/null "http://api.example.net/resource/123" * Host api.example.net:80 was resolved. * IPv4: 127.0.0.1 ##### snipped ##### > DELETE /resource/123 HTTP/1.1 > Host: api.example.net ##### snipped ##### < HTTP/1.1 204 No Content < Server: sg-httpbin-lite/1.0 Python/3.12.3 < Date: Sat, 10 Jan 2026 05:14:55 GMT < Content-Length: 0
DELETE removes server-side data on many endpoints, so issuing this verb against production resources can permanently erase records.
The request section in verbose output lists the exact method and path sent on the wire and the response section confirms the returned status code.
Mohd Shakir Zakaria is a cloud architect with deep roots in software development and open-source advocacy. Certified in AWS, Red Hat, VMware, ITIL, and Linux, he specializes in designing and managing robust cloud and on-premises infrastructures.
