methods

Overview

Every request to an API carries an HTTP method (also called a verb) that states the intent of the request: read this, create that, replace it, delete it. Methods are half of how a route is identified — the same path can behave completely differently depending on the method. Understanding methods is essential because access-control and validation rules are often defined per method, and mismatches between them create real vulnerabilities.

Learning objectives

• Name the common HTTP methods and the action each expresses.
• Explain the difference between safe, idempotent, and state-changing methods.
• Describe how the same route can expose several methods with different rules.
• Recognize method-based access-control flaws and how to test for them responsibly.

Core concept

An HTTP method tells the server what you want to do with a resource. The common ones are:

• GET — retrieve a resource. Should be safe (no state change).
• POST — create a new resource or submit data for processing.
• PUT — replace a resource entirely.
• PATCH — partially update a resource.
• DELETE — remove a resource.
• HEAD / OPTIONS — metadata: HEAD returns headers only; OPTIONS reports which methods a route allows.

Two properties matter. A safe method (like GET) is not supposed to change data. An idempotent method (GET, PUT, DELETE) produces the same result whether called once or many times, while POST is generally not idempotent. These properties guide correct API design and hint at what a method should be allowed to do.

How it works

A route is identified by method + path together. So /api/v1/notes/42 may support several methods:

GET    /api/v1/notes/42   -> read note 42
PUT    /api/v1/notes/42   -> replace note 42
DELETE /api/v1/notes/42   -> delete note 42

Each method typically maps to a different handler with its own logic — and, crucially, its own authorization and validation. A frequent mistake is to protect one method but forget another: for example, carefully checking permissions on GET while leaving DELETE or PUT on the same path unprotected. The OPTIONS method can reveal which verbs a route accepts, and a route that quietly accepts an unexpected method (like PUT where only GET was intended) is a red flag.

Verb tampering describes attacks where changing the method bypasses a control — for instance, if a security filter only inspects POST requests, sending the same action as a different method might slip past it.

Practical example

In an isolated lab API, the documented behavior of /api/v1/notes/42 is that only the note's owner may change it. You confirm, using your own account, that GET correctly returns your note. Testing responsibly within scope, you observe that the GET handler enforces ownership but the DELETE handler on the same route does not re-check it — the developer assumed "if you can see it you can delete it." The lesson is structural: because each method is handled separately, each one needs its own authorization check. The fix is to apply the ownership check to every method on the route, not just the one that was tested first.

Cybersecurity relevance

Method handling is a recurring source of API weaknesses. Access-control rules, input validation, and rate limits are all defined per method, so gaps between methods are easy to introduce and easy to miss. Defenders address this by: restricting each route to only the methods it needs (and returning 405 Method Not Allowed for the rest), applying authorization and validation to every accepted method, and never assuming a filter that inspects one verb covers the others. In authorized testing, systematically checking each method on a route — with permission and against lab targets — surfaces these inconsistencies before attackers do.

Common mistakes

• Protecting one method and forgetting the others on the same route (e.g., securing GET but not DELETE/PUT).
• Assuming a filter that inspects POST also covers PUT/PATCH/DELETE — the basis of verb-tampering bypasses.
• Allowing methods a route does not need, widening the attack surface instead of returning 405.
• Using GET to change state, breaking the "safe method" expectation and enabling issues like cacheable side effects.

Key takeaways

• The HTTP method expresses intent (GET read, POST create, PUT replace, PATCH update, DELETE remove); a route is identified by method + path together.
• Safe methods should not change state; idempotent methods can be repeated with the same effect — these properties guide correct design.
• Each method on a route is handled separately and needs its own authorization and validation; gaps between methods cause real vulnerabilities.
• Defenders allow only needed methods, return 405 otherwise, and enforce checks on every accepted verb.

Check your understanding

• Why does a single route path require authorization checks on each HTTP method rather than just one?
• What does it mean for a method to be "safe" versus "idempotent," and why do those properties matter for API security?