Skip to content
intermediate2 min readFree guide

Test an API by checking status, headers and body together

InterviewSolutionHub learning library · Updated

On this page

A request tool can show what a server actually returned. Use it to investigate a specific contract and keep test requests separate from real customer actions.

State the expected contract

Write down the method, URL, authentication requirement and expected response shape. Choose an example endpoint in a local or documented test environment. A status code alone is incomplete evidence: verify the body, relevant headers and whether the action changed state as intended.

Inspect failures without exposing secrets

curl can display response headers and a response body, while its own process exit status describes a separate client-level outcome. Options change failure handling, so read the tool’s documentation. Redact credentials and private payloads before sharing an example. Never paste a live token into a public issue or tutorial.

Test negative cases deliberately

Check missing authentication, invalid input, missing resources and repeated submissions when relevant. A retry of a state-changing action can repeat a real effect. Use fictional data and a suitable test environment, and verify that rejected requests do not mutate protected records.

Worked example

For a local API that you control, inspect a known successful GET and a known missing resource. Compare the status, Content-Type header and body. If an HTML sign-in page appears where JSON was expected, investigate the redirect or authentication flow before changing the JSON parser.

Check your understanding

Try each question before opening its explanation. These are free practice prompts; they do not use game chances.

Is a curl exit status identical to an HTTP status code?

No. They describe different layers. The process status reports client execution according to its options, while the HTTP status is part of the server response.

Why can retrying a POST be risky?

The first request may already have taken effect even if its response was lost. Important writes need a deliberate duplicate-handling policy, not blind repetition.

What should you include in a redacted API bug report?

Include the method, safe URL shape, relevant status and headers, a non-sensitive response example and reproduction steps. Remove tokens, cookies and personal information.

Sources and further reading

These original examples explain foundational concepts. Use the official references for complete, current details and version-specific behaviour.

About this guide: AI-assisted educational content with original examples and linked primary references. Found an issue? Tell us what to improve.

Keep exploring Developer tools

All subtopics →