How to specify the HTTP method in cURL

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.

1. Open a terminal on any system where cURL is installed.
2. Send a request without specifying a method to observe the default GET behavior.

   $ curl --silent https://example.com/resource
   {
     "id": 123,
     "status": "ok"
   }

   Without additional method options, cURL sends a GET request for HTTP and HTTPS URLs.

3. Override the default method with --request to send a POST request.

   $ curl --silent --request POST "https://example.com/resource"
   {
     "id": 123,
     "status": "created"
   }

   Short form -X POST performs the same override but long options keep commands easier to read in shared examples.

4. Attach form-style data with --data when the chosen method expects a request body.

   $ curl --silent --request POST --data "field=value" "https://example.com/form"
   field=value

   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.

5. 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"}' \
     "https://api.example.com/items/1"
   {
     "id": 1,
     "status": "updated"
   }

   Matching method, URL, and media type with API documentation avoids responses such as 400 Bad Request or 415 Unsupported Media Type.

6. Use a safe method such as HEAD when only response headers and status information are required.

   $ curl --silent --head --include "https://example.com/"
   HTTP/2 200 
   alt-svc: h3=":443"; ma=2592000
   content-type: text/html
   date: Sun, 21 Dec 2025 10:02:09 GMT
   ##### snipped #####

   HEAD returns headers without a response body, which speeds up checks against large resources.

7. Test API-specific verbs such as PATCH or OPTIONS by passing the verb name directly to --request.

   $ curl --silent --request OPTIONS --include "https://api.example.com/items"
   HTTP/2 204 
   allow: GET,POST,OPTIONS
   alt-svc: h3=":443"; ma=2592000
   date: Sun, 21 Dec 2025 10:02:13 GMT
   ##### snipped #####

   Most APIs accept PATCH for partial updates and may advertise supported verbs in the Allow header or in separate documentation.

8. 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 "https://example.com/resource/123"
   * Host example.com:443 was resolved.
   * IPv4: 172.17.0.5
   ##### snipped #####
   > DELETE /resource/123 HTTP/2
   > Host: example.com
   ##### snipped #####
   < HTTP/2 204 

   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.