Headers & Methods from the Terminal

Choose a method for the request

HTTP methods describe the kind of action a client intends. A basic curl request usually uses GET, which asks for a resource. POST sends data to a server, commonly to create a record or start an action. Your quest explores request and response behaviour, so choosing the method is part of expressing what you want the server to do.

Use -X POST to select POST explicitly. If the server expects JSON, add a content-type header with -H Content-Type: application/json. The header tells the server how to interpret the body; without it, the server may not parse the data as intended.

Send a JSON body

Use -d to provide request data. Keep the JSON valid: property names and string values need double quotes. A small example looks like this:

curl -X POST https://example.com/items \\
  -H "Content-Type: application/json" \\
  -d '{"name":"badge"}'

The command demonstrates the shape of a request, not a real endpoint or a complete quest answer. Use the URL and fields supplied by your activity. Inspect the response status and body to see whether the server accepted the request.

Learn by provoking responses

You can deliberately make requests that produce useful error codes on an authorised test endpoint. A malformed request may result in 400 (bad request); an endpoint requiring credentials may return 401; a misspelt or absent route may return 404. These codes reveal different failure categories. Do not treat every failure as the same problem: check the status line and response body.

A 400 often points to invalid input or formatting. A 401 indicates authentication is missing or invalid. A 404 means the requested route or resource was not found. The server’s details help confirm which case occurred.

Be careful with writes

POST can create data, so test against a playground or a system you have permission to use. Repeating a write may create multiple records. Use small, non-sensitive sample data, and inspect the response before sending another request.

For your terminal activity, vary one part at a time—method, header, body or URL—then compare the response. This controlled approach teaches how each request component affects the result.

First finish the read-only network activity

Activity 3.1 asks for four GET responses with headers; it does not require creating or deleting data. Reuse the previous lesson's four URLs and curl -i/curl.exe -i. Compare 200, 400, 401 and 404 one at a time. Changing -i to -I changes to HEAD and may produce different results, so it is not equivalent evidence.

Read the request and response separately: a request Content-Type describes what you sent; a response Content-Type describes what came back. The status line belongs to the response. The server can reject a perfectly formatted command because that route or method is unsupported.

Optional safe POST echo rehearsal

The earlier example.com/items example is only a shape—not a functioning API. To inspect a POST without changing a real product, use an authorised public echo endpoint such as httpbin.org/post and harmless data. Public services may be unavailable; do not send secrets.

Create practice-request.json in your editor:

{"name":"Practice badge"}

Mac:

curl -i https://httpbin.org/post -H "Content-Type: application/json" --data-binary "@practice-request.json"

PowerShell:

curl.exe -i https://httpbin.org/post -H "Content-Type: application/json" --data-binary "@practice-request.json"

The file-based command avoids platform-dependent inline JSON quoting. --data-binary supplies a body and selects POST; -X POST is unnecessary here. A quoted header is one argument. Compare the echoed method, headers and parsed JSON with what you intended. This service echoes the request; it does not add a product to your database.

Run one controlled variation without the JSON Content-Type header and inspect how the server reports the body. Do not assume every API will reject or accept it in the same way. HTTP method semantics describe intent; the API's contract still defines the accepted request.

Before assessment, explain the difference between the read-only GET evidence and optional POST practice. Never experiment with DELETE, purchases or repeated writes on a service you do not own. A response showing your data was echoed is not proof a durable write occurred.