PUT is an HTTP method commonly used in REST APIs to update a resource at a URL. A REST URL names the resource, while the HTTP method supplies the action, so one URL can support GET, PUT, and other operations. For example, `/api/song/42/` identifies song 42; a PUT request sends replacement data for that song. section 11.1.1
The practical distinction is payload size and intent: PUT expects all fields of an object, while PATCH sends only fields that changed. REST conventions are flexible rather than enforced, so an API’s documentation remains the final authority on whether it uses PUT, PATCH, or POST for updates. section 11.1.1 section 11.2.7
Replacing a venue through Django Ninja
A PUT endpoint places the existing venue ID in the route and receives a `VenueIn` payload. It finds the `Venue`, loops through every payload field, uses Python’s `setattr()` to assign each value, saves the model, and returns the updated venue. Because PUT supplies all fields, the same serializer used for creation can also serve this update. section 11.2.7
Listing 11.14 A update endpoint for venues
# RiffMates/bands/api.py
...
@router.put("/venue/{venue_id}/", #1
response=VenueOut, auth=api_key) #2
def update_venue(request, venue_id, payload:VenueIn): #3
venue = get_object_or_404(Venue, id=venue_id) #4
for key, value in payload.dict().items():
setattr(venue, key, value) #5
venue.save() #6
return venue
The listing traces a complete PUT update: route declaration, authentication, object lookup, field assignment, save, and response. section 11.2.7
Choose PUT when full replacement data is the simpler fit:
- Use it when a browser, single-page app, or mobile client already holds and sends the whole object. section 11.2.7
- Prefer PATCH when a model has many fields or large data such as attachments and sending only changes is worthwhile. section 11.2.7
- Expect PATCH to need a separate schema with optional fields; its update loop otherwise works like PUT. section 11.2.7
