[Feature] Add `PATCH` support or partial updates to enable incremental edits

[a-earthperson]

Is there an existing issue for this feature?

• Yes, I have searched the existing issues and it doesn't exist.

Feature Description

This is a potentially dangerous one, I know, since it could have side-effects. And I suppose supporting a schema that is usable by REST API clients that aren't the app's frontend might even be out of scope. But I'll take a shot anyway:

---

The current Resume REST API supports only full replacement updates via PUT /resume, i.e. does not support partial updates via PATCH. This forces REST API clients to submit a complete, schema-valid resume document for every change, even when the user intent is a small incremental edit (e.g., “add one job bullet”, “update phone number”, “append one award”).

For any API client that isn't the app's frontend, this constraint significantly increases integration complexity, creates poor UX for incremental editing flows, and leads to avoidable validation failures during automation.

For example, I have been toying around with an MCP-driven resume creation flow, where the agent/client starts from sparse user input (often plaintext), then progressively refines the resume into the API’s strict schema. Without PATCH, each refinement requires:

1. Fetching the entire resume object (GET) to avoid overwriting unrelated fields.
2. Constructing a full replacement payload that must satisfy all schema constraints (including required boilerplate like id, hidden, and nested default objects).
3. Sending the whole document via PUT.
4. Handling broad validation failures that may involve dozens of unrelated fields.

This makes small edits disproportionately difficult and brittle, especially for tool-based agents that build the resume iteratively.

Pain Points

1. High coupling to internal schema
   • A client cannot easily submit “just the new award”; it must send a fully valid awards list with required fields and IDs.
2. Boilerplate amplification
   • Even minimal resume authoring requires producing fields that are not semantically part of the edit (e.g., setting hidden=false, generating id).
3. Large payloads and fragile transformations
   • Simple edits require sending the full data object, often including HTML strings, templates/layout metadata, etc.
4. Error recovery is expensive
   • One invalid field blocks the entire PUT. Clients must repeatedly resubmit large payloads during correction loops.
5. Increased risk of overwriting
   • Without PATCH semantics, accidental loss of existing data is easier if the client does not round-trip the current state perfectly.

Recommended semantics

• Accept a partial document that updates only specified fields.
• Preserve unspecified fields on the server.
• Support one of the following patch formats:
  1. RFC 6902 JSON Patch (application/json-patch+json)
     • Pros: precise operations (add/replace/remove), good for arrays, standardized.
  2. RFC 7396 JSON Merge Patch (application/merge-patch+json)
     • Pros: simpler for clients; good for object merges.
     • Cons: less precise for array operations (often replaces entire arrays).
  3. (Optional) A domain-specific patch DSL for section items (append/update/remove by id), but JSON Patch is usually sufficient.

Array and section editing requirements

To enable section-wise incremental edits, PATCH must support safe manipulation of arrays under sections, e.g.:

• Append an item to /data/sections/experience/items
• Replace a single item’s description at /data/sections/experience/items/{index}/description
• Remove an item
• Reorder items (either by explicit reorder operation or replace with new array)

JSON Patch provides these operations cleanly.

Nice-to-Haves / Related Improvements (Optional, but strongly synergistic)

• ETag / If-Match support for optimistic concurrency control to prevent lost updates in concurrent edit scenarios.
• Server-side defaults for boilerplate fields when appending items (e.g., auto-generate id, default hidden=false), though this can also be handled at PATCH time.
• Return the updated resource (or at least a revision identifier) in PATCH responses to reduce follow-up GET calls.

Acceptance Criteria

• A client can create a resume with minimal scaffolding, then incrementally add/edit sections without resending the entire resume document.
• PATCH updates only the specified fields; unrelated fields remain unchanged.
• Clients can safely append and update section items without reconstructing full arrays (or, if merge patch is used, provide a supported approach for array edits).
• Validation errors (if any) reference only the patched paths where possible and remain actionable.

Example (JSON Patch)

Append a new award without re-sending all resume data:

PATCH /resume/{id}
Content-Type: application/json-patch+json
If-Match: "rev-123"   # optional but recommended

[
  {
    "op": "add",
    "path": "/data/sections/awards/items/-",
    "value": {
      "title": "Graduate Merit Award - Summer 2025",
      "awarder": "College of Engineering, NCSU",
      "date": "Summer 2025",
      "hidden": false
    }
  }
]

[a-earthperson]

I have opened a draft pull request #2651 for this feature, I will change its status to draft once its ready for review @amruthpillai.

[a-earthperson]

I am linking PR #2675 since PR #2651 introduces too many breaking changes