HTTP Method Tester
Compare HTTP method semantics and build request examples without sending anything to an endpoint.
Enter an API endpoint, route, or example URL. The review stays in your browser and does not send a request.
Method Settings
Options
Keep only the headers and checks that belong in the example you are preparing. Warnings describe protocol-level concerns; the endpoint contract still decides what the server accepts.
Method semantics matter more than CRUD labels
GET, POST, PUT, PATCH, DELETE, HEAD, and OPTIONS are protocol methods, not a fixed CRUD vocabulary. An API can give a POST endpoint resource-specific processing semantics without creating anything, and DELETE expresses removal of the target resource association rather than promising that every underlying record or file is physically erased. Treat the API contract as authoritative when it narrows or extends the general HTTP meaning.
RFC 9110 defines GET, HEAD, and OPTIONS as safe methods. PUT and DELETE are not safe, but they are idempotent by definition: repeating the same intended request should have the same intended effect as sending it once. POST is not inherently idempotent, and RFC 5789 makes the same point for PATCH, although an API can design a particular POST or PATCH operation to be idempotent.
Standards: RFC 9110, HTTP methods and RFC 5789, PATCH.
Request content is not simply allowed or forbidden
POST and PUT define clear semantics for request content, and PATCH carries a patch document whose media type tells the server how to apply the change. GET, HEAD, and DELETE are different: RFC 9110 says request content has no generally defined semantics for them and clients should not generate it unless the origin server has explicitly indicated support. OPTIONS can contain content, but HTTP itself assigns no meaning to it and requires a valid Content-Type when it is present.
A warning here means “unusual or contract-dependent,” not “HTTP syntax makes this impossible.”
Retry decisions belong to idempotency
A network timeout creates an awkward question: did the server apply the request before the connection failed? Idempotent methods give clients more room to retry automatically because repeating the same intended operation should not multiply its intended effect. That does not make PUT or DELETE harmless, and it does not mean every library should blindly retry them. Preconditions such as If-Match can matter when concurrent updates are possible.
PATCH deserves extra care when the patch depends on a known base version; RFC 5789 specifically discusses conditional requests for collision-sensitive patch formats.
Caching rules differ by method
GET and HEAD have normal cache semantics. POST responses can be cached only under specific conditions, including explicit freshness information and a matching Content-Location. PUT and DELETE responses are not cacheable under RFC 9110, and successful requests can invalidate stored responses for the target URI. OPTIONS responses are also not cacheable. PATCH has its own narrower cache rules in RFC 5789.
The generated summary is a protocol reference, not a prediction of what a particular CDN, framework, reverse proxy, or application cache will do. Cache-Control, validators, authorization, intermediary configuration, and application behavior still decide what happens in a real deployment.
Generated commands are examples, not live verification
Nothing entered here is sent to the endpoint. That protects you from accidentally executing a destructive example, but it also means the page cannot confirm whether a route exists, which methods the server actually allows, whether credentials work, whether a request will pass CORS, or what status code and response body will come back. Run copied commands only against an environment where the operation is safe.
Browser CORS warnings describe request shape only
Frontend requests can require a CORS preflight when the method is not CORS-safelisted or when headers and Content-Type fall outside the safelisted request-header rules. Authorization and application/json commonly lead to preflight. The warning is intentionally conservative because the browser also considers header values and the server's CORS response.
Reference: WHATWG Fetch CORS protocol.
Read the generated fetch snippet before using it
The fetch output builds the request only. It does not assume that every response contains JSON, because HEAD responses have no response content and successful APIs can return text, binary data, 204 No Content, or another media type. Response parsing belongs to the caller after checking status and Content-Type. Custom headers are treated as example input; verify required names, values, authentication schemes, and content types against the API documentation before running the request.