HTTP verb: PUT
This course explains the HTTP PUT method. It covers how PUT replaces a resource at a known URL or creates it there, and why the request body must hold the full representation. It explains idempotency and why it makes retries safe, then compares PUT with POST. Later lessons cover the status codes a PUT response returns, method spoofing for HTML forms that only support GET and POST, and how Rails routes PUT requests to the update action.
What you'll learn
- ✓How PUT replaces or creates a resource at a specific URI
- ✓What idempotency means and why it allows safe retries
- ✓How PUT differs from POST in targeting and repeatability
- ✓The status codes 200, 204 and 201 in PUT responses
- ✓Method spoofing with a hidden _method field in HTML forms
- ✓How Rails maps PUT requests to the update action
What is the PUT method?
The HTTP PUT method has one job. It replaces the resource at a specific URL, or creates it if it doesn't exist yet.
Read the full lesson free →Curriculum
7 lessonsWhat is the PUT method?
PUT replaces the resource at a URL or creates it, and requires the full representation in the body.
The concept of idempotency
Idempotent operations give the same result when repeated, which lets clients retry failed PUT requests safely.
Anatomy of a PUT request
A PUT request targets a specific URI, carries a complete body and uses Content-Type and Content-Length headers.
PUT vs POST
POST targets a collection and creates duplicates when repeated, while PUT targets a known resource and is idempotent.
The response of a PUT request
A successful PUT returns 200 OK with data, 204 No Content with an empty body, or 201 Created.
HTML forms and PUT
HTML forms cannot send PUT, so frameworks read a hidden _method field, while JavaScript fetch sends real PUT.
PUT requests in Rails
Rails routes PUT to the update action, and form_with adds the hidden _method field for existing records.