Choose a method deliberately

You rarely tell curl which HTTP method to use. The options you pick imply one.

A plain URL produces GET. --data implies POST, because sending a body is what POST is for. --head sends HEAD. --upload-file implies PUT. Each option switches the method because the method matches what the option does.

Then there’s --request (short form -X). It changes the method string, and nothing else. It swaps one word in the request line. It does not add the behavior you’d expect from that method.

See the difference

Compare a HEAD request with an explicit custom method:

curl --head https://example.org/
curl --request DELETE https://httpbin.org/anything

The first command prints headers and then stops. That’s real behavior. curl knows a HEAD response carries no body, so it doesn’t wait for one.

The second command sends DELETE, and httpbin confirms it:

{
  "method": "DELETE",
  "data": "",
  "json": null
}

But curl didn’t invent authentication, a body, or any deletion logic. It sent an ordinary request whose method token happens to say DELETE. Whether anything gets deleted is entirely up to the server.

Where -X goes wrong

The classic mistake is -X GET combined with --data. The request line says GET, but a body still goes out, because -X only renames the method. Some servers ignore a body on GET. Others reject it. Either way, you sent something you didn’t mean to.

If you want a GET with data in the URL, use --get with the data options, like we did in the query string lesson. That’s the tool for the job, not -X.

Another one I see a lot: -X POST added to a command that already has --data. It’s redundant. curl was going to POST anyway. It’s harmless here, but it trains you to type -X by reflex, and the reflex is what breaks the GET case.

My advice: reach for -X only when the API needs a method curl has no native option for, like DELETE or PATCH. Let curl’s own options pick the method everywhere else. They adjust the rest of the request to match.

Be careful with destructive methods

Use the method the API contract asks for, and slow down on the destructive ones. A successful connection does not mean a DELETE was authorized, or safe.

Point DELETE and PATCH at test endpoints like httpbin.org/anything until you’ve read what the real API does with them. Try it now: send a PATCH with --request PATCH --json '{"active":false}' to that endpoint and check that both the method and the body arrived as you expected.