How can you design RESTful APIs that support partial updates?

A partial update is an operation that updates only part of a data entity. This "partial" vs "whole" is in practice subjective, because the boundary of which an operation deals with whole or partial data entity cannot usually be defined clearly. In essence, however, usually what we call by partial updates are operations that update some attributes such as employee name, address, change user password, etc.

A partial update refers to the process of modifying only a subset of resource properties within an entity, leaving the rest unchanged. In the context of RESTful APIs, this allows clients to update specific fields of a resource without sending the entire payload.

Of course because it is cheaper. It makes sense if the only thing that needs to be updated is the password, then you send only new password to the backend, and not the whole user data again. The most basic reason is just not to be wasteful.

Efficiency: Sending only the modified fields reduces the payload size and minimizes the data transferred over the network. Concurrency Control: Partial updates are essential for scenarios where multiple clients may be modifying different parts of a resource simultaneously, preventing unintentional overwrites.

There is nothing special about partial updates in the standpoint of HTTP API. Usually PATCH or POST is used but not PUT. The most important considerations lie in the data manipulation methods. Update requests to databases have to be created specifically for each update operation, and not all databases support efficient partial updates. It is also more difficult to implement effective ACID principle for partial update operations.

HTTP PATCH Method: Utilize the HTTP PATCH method to perform partial updates. Unlike PUT, which requires sending the entire resource, PATCH allows clients to submit only the fields they want to update. JSON Merge Patch or JSON Patch: Choose an appropriate format for partial updates. JSON Merge Patch and JSON Patch are common standards. Merge Patch sends the changes as a JSON object, while Patch uses a list of operations to apply on the resource. Conditional Requests: Implement conditional requests using ETags or Last-Modified headers to ensure the resource hasn’t been modified by another client since it was retrieved.

Clear Documentation: Explicitly state which fields can be partially updated and the format expected. Include examples to illustrate proper usage. API Schema: Maintain an up-to-date API schema to provide clients with insight into the structure of resources, making it easier for them to identify fields available for partial updates.

You just do unit, behavior, and integration tests as usual. There is nothing special about partial updates as in testing standpoint, they are just like any other API operations.

Unit Tests: Create unit tests to verify that partial updates are applied correctly. Ensure that the expected fields are modified while others remain unchanged. Integration Tests: Perform integration tests to simulate real-world scenarios, including concurrent partial updates, and validate the system's behavior. Negative Testing: Test for edge cases and provide proper error responses when clients attempt to perform partial updates on non-updatable fields.