Requests and responses
Use the request method attributes
Choose hx-get, hx-post, hx-put, hx-patch, or hx-delete to match the meaning of the server operation.
Each request attribute takes a URL and tells HTMX which HTTP method to use:
<button hx-post="/tasks">Create task</button>
<button hx-patch="/tasks/42">Complete task</button>
<button hx-delete="/tasks/42">Delete task</button>
Use the HTTP method to describe the operation:
hx-getretrieves a representation without changing server statehx-postcommonly creates a resource or performs a commandhx-putreplaces a resource representationhx-patchapplies a partial changehx-deleteremoves a resource
The attribute only declares a request. The server still needs a matching route, authentication, authorization, validation, and CSRF protection for state-changing methods. HTMX does not save you from any of that.
HTMX 2 sends values for DELETE in URL parameters by default, aligning it with the current specification behavior. Do not assume the request body format from an older HTMX version. Inspect the actual request in the Network panel and configure your server parser accordingly.
GET must remain safe because browsers, crawlers, caches, and prefetchers may repeat it. A route that deletes on hx-get is dangerous even if the current button is the only visible way to call it. I have seen hx-get used for “refresh list” and hx-delete on a separate control. Keep that separation clear in your markup and in your routes.
Open the Network panel and verify method, URL, and parameter location for each example. A PATCH that shows up as POST with a method override is a server framework detail, not an HTMX surprise, but you should know which pattern your stack uses.
Use GET for safe retrieval. Use a state-changing method for create, update, or delete actions.
Try this on your own project: list your HTMX routes and confirm no GET route mutates data.
Lesson completed