liveBook · Manning

PATCH

As explained in Django in Action

PATCH is an HTTP method that requests partial modification of a resource using only changed fields.

PATCH is an HTTP method for partially updating a resource. Instead of resending every field of an object, a client sends only the fields that changed. In REST-style APIs, it is commonly paired with a resource URL such as `/api/song/42/`; the URL identifies the song, while PATCH supplies the action. section 11.1.1

Figure 11.2 GET, POST, PUT, PATCH, and DELETE: HTTP methods for CRUD actions
figure

Use the CRUD mapping as a quick mental model: PATCH and PUT are both update operations, but PATCH carries only changed fields. section 11.1.1

PATCH is a convention rather than an HTTP-enforced rule. REST does not prevent an API from using POST for updates or choosing different method behavior, so clients must follow that API’s documentation. Keep verbs out of REST URLs: the HTTP method expresses the operation, letting one resource URL support fetching, updating, and deleting. section 11.1.1

In Django Ninja, PATCH is registered with a PATCH decorator. Its update flow otherwise resembles PUT: find the existing object from the ID in the URL, loop over the submitted payload fields, assign each value with `setattr()`, save the object, and return it. The important difference is that the payload contains only supplied changes. section 11.2.7

A PATCH endpoint needs a schema designed for partial input:

  • Make fields optional. A normal `ModelSchema` reflects required model fields, but PATCH cannot require fields the client did not change. section 11.2.7
  • Build the input schema manually with Python `Optional` type hints when the model has required fields. section 11.2.7
  • Weigh the extra serializer work against the payload savings. PATCH can help with models containing many fields or data-heavy fields such as attachments. section 11.2.7

Choosing PUT or PATCH for a venue

A client updating a venue with every field available can use PUT and send the full object. A client that knows only the venue’s changed fields can use PATCH and send those fields alone. Single-page and mobile clients often choose PUT when they already send whole objects and do not track field-level edits; PATCH fits clients that do track those edits. section 11.2.7

PATCH is one piece of a CRUD API: GET reads, POST commonly creates, PUT and PATCH update, and DELETE removes. JSON or XML may carry the payload, but the client still needs to know the API’s expected method and payload format. section 11.5

How Django in Action covers it

How deep it goes
Walks through Django Ninja’s schema requirement and field-by-field save flow, while deferring a complete PATCH listing.
Examples
Contrasts full-object PUT with changed-field PATCH for venue updates, SPAs, mobile clients, and attachment-heavy models.
What it assumes
Introduces PATCH through CRUD and REST conventions while assuming enough Python to use `Optional` and `setattr()`.
What you can do after
Apply it via Django Ninja by defining an optional-field schema and updating only submitted model fields.
How it connects
Connects PATCH with REST, CRUD, PUT, POST, DELETE, URLs, JSON, XML, Django Ninja, ModelSchema, and ORM models.

Also explained in

Compare how 4 books explain PATCH →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Django in Action. The section links point to the parts of the book it draws on.