methods

Overview

HTTP methods (also called verbs) express what a client wants to do with a resource — fetch it, create it, replace it, delete it. Choosing and recognizing methods correctly matters for both correct web design and security testing. This lesson covers the common methods and their intended semantics.

Learning objectives

• Identify the common HTTP methods and their purposes.
• Distinguish safe and idempotent methods.
• Connect methods to REST-style resource actions.

Core concept

The common HTTP methods:

• GET — retrieve a resource; should not change server state (safe).
• POST — submit data to create or trigger processing (not idempotent).
• PUT — replace a resource entirely (idempotent).
• PATCH — partially update a resource.
• DELETE — remove a resource (idempotent).
• HEAD — like GET but returns headers only, no body.
• OPTIONS — ask which methods/capabilities a resource supports.

Safe methods do not modify state; idempotent methods produce the same result whether called once or many times.

How it works

Methods communicate intent, and well-designed applications honor that intent: a GET should be a read, a DELETE should remove. REST APIs map methods to actions on resources (GET /users/1 reads, PUT /users/1 replaces, DELETE /users/1 removes). Servers may implement only a subset, and OPTIONS lets a client discover which are allowed. Because GET is "safe," it should never be used to perform state-changing actions — doing so causes real bugs and security issues.

Practical example

For a user resource:

• GET /users/42 — fetch user 42's details.
• POST /users — create a new user (data in the body).
• PUT /users/42 — replace user 42's record.
• PATCH /users/42 — change just one field (e.g. email).
• DELETE /users/42 — remove user 42.

The same path behaves differently depending on the method used.

Cybersecurity relevance

Methods are a security focus. Testers check whether state-changing actions are wrongly allowed via GET (which can enable CSRF-style attacks or logging of sensitive data in URLs), whether dangerous methods (PUT, DELETE) are unintentionally enabled, and whether access controls apply consistently across methods (a resource protected for GET but not for DELETE is a flaw). OPTIONS responses reveal a resource's allowed methods during recon.

Common mistakes

• Using GET to change state — it should be safe/read-only.
• Confusing safe with idempotent — GET is both; DELETE is idempotent but not safe.
• Assuming access control on one method covers all — each method must be checked.

Key takeaways

• Common methods: GET (read/safe), POST (create/process), PUT (replace), PATCH (partial update), DELETE (remove), HEAD (headers only), OPTIONS (capabilities).
• Safe methods do not change state; idempotent methods give the same result on repeat calls.
• Methods carry security weight — misused GETs, exposed dangerous methods, and inconsistent access control across methods are common findings.

Check your understanding

• Which methods are idempotent, and which single common method is considered "safe"?
• Why is performing a state-changing action via a GET request a security problem?