A nickname field is empty. Does that mean leave the stored nickname alone, remove it, or reject the request? A form can make these choices look identical while the person using it intends three different things.
I would start with the update contract. For a hypothetical nickname API, an omitted field could mean keep the current value, null could mean clear it, and an empty string could be invalid. Those are deliberate choices for this example. The word PATCH does not give every API these exact semantics.
The distinction can disappear before the request arrives
Here is a small JavaScript example, checked in Node.js v26.0.0:
JSON.stringify({ nickname: undefined }); // '{}'
JSON.stringify({ nickname: null }); // '{"nickname":null}'
JSON.stringify({ nickname: '' }); // '{"nickname":""}'As the JSON.stringify reference explains, an undefined object property is omitted during serialization. An array behaves differently: an undefined element is serialized as null. The shape around the value matters.
On the server, a fallback expression can erase the distinction again. Treating every false-like input as missing might combine an empty string with values such as zero or false in a different field. Parsing should preserve enough information for validation to make the product decision.
| Example input | Chosen behavior |
|---|---|
| {} | Keep the nickname |
| {"nickname": null} | Clear it |
| {"nickname": ""} | Reject without changing stored data |
This table is an example contract, not a universal serialization or PATCH rule. A service using a defined patch format must also follow that format. An older API might already use the empty string to clear a field; changing its documentation does not update existing clients.
A clear action is easier to preserve than an ambiguous blank
A form can keep track of untouched fields and provide a distinct remove action. That is more explicit than sending every control back as an empty string and asking the server to reconstruct intent.
I would also inspect the stored value after a rejected request. Returning a validation error while changing the nickname would satisfy the response assertion and still fail the user. The relevant result includes both the error and the unchanged state.
There is no prize for reducing these cases to the shortest condition. The extra distinction is carrying someone's intention. Losing it is a behavior change, even when the JSON still looks tidy.
한국어 글: API에서 값이 없다는 말은 하나가 아니다