List the main HTTP methods and what each is used for.

HTTP methods (verbs) describe the intent of a request. The mapping isn't enforced — a POST endpoint can do whatever it wants — but well-designed APIs follow conventions.

The set you'll see daily:

• GET — read a resource. Safe (no side effects), idempotent (same result however often you call), cacheable. GET /users/42.
• POST — create or trigger an action. Not idempotent — calling twice creates two records. POST /users.
• PUT — replace a resource. Idempotent. PUT /users/42 with full body sets the resource to that state.
• PATCH — partial update. Usually idempotent (depends on the patch document). PATCH /users/42 with { name: "Alice" } updates just name.
• DELETE — remove a resource. Idempotent (deleting twice still leaves it deleted). DELETE /users/42.
• OPTIONS — describe what's allowed at this URL. The browser uses it for CORS preflight.
• HEAD — like GET but no response body. Used for existence checks and metadata.

Properties testers care about:

• Safe: GET, HEAD, OPTIONS — should not modify state. If they do, it's a bug.
• Idempotent: GET, HEAD, OPTIONS, PUT, DELETE. Test by calling twice; the second call should be identical (and not produce duplicates).
• Cacheable: GET (and HEAD). Caching infrastructure can intercept; tests should account for stale cached responses.

Tester-relevant behaviours:

• POST that's not idempotent makes retry-on-failure dangerous. APIs often add an idempotency key header (Idempotency-Key) so retries produce one resource. Worth testing.
• DELETE on a missing resource should return 404 (or 204 with "already gone" semantics — confirm the API's choice).
• PUT vs PATCH semantics — see the dedicated PUT-vs-PATCH question for the field-replacement nuance.