cURL and web requests

cURL is a command-line tool for sending requests to web servers and APIs. It is useful for testing endpoints, inspecting headers, sending authentication data, reproducing browser requests and interacting with APIs without opening a browser.

When no HTTP method is specified, cURL sends a GET request by default. This is the simplest way to retrieve the content returned by a web endpoint.

The -O option saves the response using the remote filename. The -s option enables silent mode and removes progress output.

Verbose mode is one of the most useful cURL options when troubleshooting. The -v flag displays connection information, outgoing request headers and incoming response headers.

The -I option sends a HEAD request and returns only response headers. The -i option keeps the normal response body but includes the response headers above it.

A HEAD request is similar to GET but normally returns only metadata such as status code, content type, server information, cookies and caching headers. It is useful when you want to inspect an endpoint without downloading the full body.

The -k option disables TLS certificate verification. This is useful in controlled environments using self-signed certificates, but it should not be treated as a normal production configuration.

The User-Agent header identifies the client making the request. Some applications change behaviour depending on this header, so cURL allows it to be modified with -A.

The -H option adds or overrides HTTP headers. This is frequently used for authorization tokens, content types, API keys and custom application headers.

HTTP Basic Authentication sends a username and password as an Authorization header. cURL can generate this header automatically with -u.

GET parameters are appended to the URL after a question mark. Multiple parameters are separated with an ampersand. Quoting the full URL avoids shell interpretation issues.

The -d option sends request data. When used with standard key=value form data, cURL automatically uses POST unless another method is explicitly selected.

APIs frequently expect JSON instead of traditional form data. The body is passed with -d and the Content-Type header tells the server that the payload is JSON.

Web applications often use cookies to maintain sessions. The -b option sends cookies with the request, making it possible to reproduce an authenticated browser session from the command line.

A useful extension to the basic cookie workflow is to save cookies returned by the server and reuse them later. -c writes cookies to a file, while -b can read them back.

The -X option explicitly selects the HTTP method. GET reads data, POST commonly creates or submits data, PUT updates a resource, and DELETE removes a resource when the API supports those operations.

REST-style APIs usually expose resources through predictable URLs. A GET request can retrieve one entry or an entire collection.

API responses are often returned as JSON. Piping the output to jq makes nested JSON easier to read and inspect.

A POST request is commonly used to create a new resource. The exact JSON fields depend on the API contract.

PUT is commonly used to replace or update an existing resource. Some APIs use PATCH for partial modifications instead, so always check the API behaviour.

DELETE requests are normally used to remove a resource identified by its URL.

Some endpoints respond with HTTP redirects instead of returning the final page directly. The -L option tells cURL to follow Location headers automatically.

When scripting or quickly validating endpoints, it can be useful to ignore the response body and print only the status code.

cURL exposes the raw HTTP response, so understanding status codes is important. 200 generally means success, 301 and 302 indicate redirects, 401 indicates missing or invalid authentication, 403 means the server understood but refused the request, 404 indicates the resource was not found, and 500 indicates a server-side error.

Browser developer tools are useful for understanding the requests generated by a web application. The Network tab shows request methods, URLs, headers, cookies, parameters, request bodies and server responses. Once a request is understood, it can often be reproduced with cURL.

When analysing a request in DevTools, start with the method and URL, then inspect request headers, cookies, query parameters or request payload, and finally review the response status, headers and body. These elements map directly to cURL options.

A good cURL workflow is to begin with the simplest request possible and add options only when needed. First retrieve the endpoint, then enable verbose output, inspect headers, reproduce authentication or cookies, and finally recreate the exact request body.

cURL is most useful when you think in terms of HTTP rather than memorising flags. Identify the method, URL, headers, authentication, cookies and body of a request, then translate each part into the corresponding cURL option.