Should the backend set a missing field to empty when the frontend omits it in an update request?

When an update API receives a request where a field is not sent, the backend should not default to updating it to NULL or an empty string. Based on our API delivery experience in 2026, first clarify whether the API semantics are full-row overwrite or partial modification: for a full-overwrite API, the caller must send back all retained fields; for a partial-update API, only the fields that are sent are processed. If the frontend sends only changed items to save traffic, but the backend overwrites the whole row, existing database values can easily be cleared. The key is to specify “whether empty values should be written to the database” in the API contract, and to add a version-number fallback for data that may be modified concurrently.

First, distinguish: is this API a “full-row overwrite” or a “partial update”?

Edit/save write APIs actually have two distinct semantics. One is a full update: the caller submits the complete business object, and the backend replaces the original data entirely with the current request. The other is a partial update: the caller submits only the fields to be changed, and the backend touches only those fields; unsubmitted fields keep their original values.

Many integration incidents happen because “the frontend assumes partial update, but the backend performs full overwrite.” If the edit page only changes a note, and the request body only carries that note, a backend using updateById to overwrite that row will reset all other fields.

• Full update (like PUT): omitted fields are usually written as empty or default values. Suitable for scenarios with few fields and submitting a whole form at once.
• Partial update (like PATCH): omitted fields remain unchanged. Suitable for scenarios with many fields, changing only one or two items, or multi-person collaboration.

The first question to ask during joint debugging: can this API overwrite the entire row?

Most production overwrite incidents happen because the API semantics were not defined clearly

There are three common causes of production data being overwritten: the frontend submits only fields bound on the page, causing hidden fields to be lost; the backend treats an empty string or null as a normal value and writes it directly; two admin systems modify the same row at the same time, and the later full-row overwrite clobbers the earlier submission.

• When the frontend misses a non-empty field, that field becomes empty after a full-row overwrite.
• When the backend decides whether to update based on empty values, fields intended to be cleared cannot be cleared, while fields that should not be cleared get overwritten.
• During concurrent editing, as soon as the later-saving user submits, the earlier saved changes are wiped out.

From our 2026 delivery experience, such null-value and overwrite issues account for a typical range of 10% to 30% of API joint-debugging rework causes. This is not merely a low-level mistake; in many cases the API documentation did not clearly define the update semantics.

A three-question method: decide whether missing fields should be touched

Instead of arguing about “whether missing fields should be updated,” use three questions to pin down the scenario.

1. First question: Does this write API process a complete form or a partial operation? A complete form should use a full update; a partial operation (e.g., changing status or avatar) should use a partial update.
2. Second question: When a field is missing, does it mean “do not modify” or “clear it”? If missing means “do not modify,” use PATCH; if missing means “clear,” require the caller to explicitly pass an empty value.
3. Third question: Can the same data be modified by multiple people at the same time? If concurrency is possible, the update condition must include a version number or update timestamp; otherwise, a later write can easily overwrite an earlier one.

The order of these three questions cannot be swapped: the first sets the API semantics, the second sets the null-value rule, and the third determines whether concurrency control is needed. Usually, the second question is unsolvable because the first question hasn’t taken a position yet.

Implementation approach: stop confusing “not sent” with “clear”

On the code level, three things must be done: distinguish full vs. partial endpoints, provide an explicit entry for fields that may be cleared, and add version validation for concurrent updates.

• For full-update APIs: the backend should ignore master-data fields such as creator and creation time; they should not participate in the UPDATE, to avoid wiping out audit information on every update.
• For partial-update APIs: if you use a framework like MyBatis, a common pattern is “if test non-empty judgment”. It blocks empty strings, so fields that are allowed to be cleared cannot be cleared. To clear a field, you need a separate SET statement or an explicit clear flag.
• For any write operation that may be concurrently modified, it is recommended to use a version field as an optimistic lock: UPDATE ... WHERE id=? AND version=?. If the affected row count is 0, return a conflict.

In an admin project delivered in 2026, the profile edit page had more than twenty fields. Initially we used a full-table updateById. After launch, a case appeared where “changing the remark reset the approval status.” The constraints were: no database triggers, and the frontend didn’t want to send back all fields for every page. We refactored the API into two write endpoints — basic info and status — where the status endpoint accepts only status fields and requires the frontend to include a version. The cost of this refactor was about 2 to 3 extra working days of joint debugging.

For this type of “semantic-splitting” refactor, the typical range for extra time is usually 2 to 5 person-days. Although it cost us two or three days at the time, the repeated overwrite rework that had been occurring largely disappeared afterwards.

Full update vs. partial update: how to choose

Choose based on the actual business shape, not on technical habits. You can quickly decide by looking at three dimensions: number of fields, concurrency frequency, and caller type.

• Fewer than 10 fields and one save writes a complete object: prefer full update — it is straightforward and usually faster to integrate.
• More than 20 fields, or only one or two fields change each time: prefer partial update — it avoids sending dozens of fields each time and lowers the risk of missing fields.
• Frequent concurrent editing, for example multiple operators maintaining the same configuration: recommend partial update plus a version number; full update can easily let the later write overwrite the earlier one.
• If the API will be used by multiple clients like mini-programs or third parties: design it with PATCH semantics, and clearly document the rules for “missing vs. null values” in the API docs.

According to the experience range from multiple projects, when the number of fields is between 10 and 20, the integration costs of the two approaches are similar. Once fields exceed 20, partial update has lower long-term maintenance cost, and null-value rework can be reduced by about 30%. If all your fields are under 10 and empty values are not allowed, a full update is still a safe choice; you don’t need to force a more complex update protocol for the sake of “standards.”

Applicable scenarios and boundaries

The above approach suits business admin systems with edit pages, management systems with status transitions, and APIs that need to be reused across multiple clients.

The boundaries are also clear: if it is a one-off data migration script or a scheduled job, the caller can always get complete data, so direct full-row overwrite has little risk and there is no need to split it into two endpoints.

If a single update has to span multiple tables and maintain atomicity, or you are writing fields inside a large JSON, the update strategy also needs transaction boundaries and JSON-granularity control; you cannot simply apply a full/partial update rule.

FAQ

When an update API doesn’t receive a field, will the backend set it to empty?

It depends on the API semantics. A full update will overwrite it with a missing value; a partial update only changes the fields that were sent. If you are unsure, first check how the API contract defines it.

What is the difference between PUT and PATCH?

Simply put, PUT submits the complete state; fields not sent are usually treated as cleared or reset. PATCH submits a description of changes; fields not sent keep their original values. The two have different levels of data safety.

What if the frontend sends an empty string to clear an address, but the backend doesn’t update it?

Empty strings and null must be handled separately. Backend code should not update only when a field is not null. For fields that are allowed to be cleared, set up a dedicated clearing entry or clear flag.

What if multiple people edit the same row at the same time and fields are overwritten?

Use a version number or an update timestamp as an optimistic lock. Include the version saved by the frontend in the update. If the affected row count is 0, tell the user to reload; don’t let the later submission simply overwrite the data.

Is it safer to change all write APIs to partial updates?

Not necessarily. Partial updates have stricter requirements for the semantics of “missing = don’t update.” If the frontend usually submits the whole entity, forcing partial updates may increase the risk of missing updates. Choose based on the scenario for greater stability.

When you start implementing, you can first spend an hour or two marking all write APIs in the current system’s documentation: whether each one is full overwrite, partial update, or no update; and for each write API, note whether omitted fields and empty values are written to the database. This step is very cost-effective for avoiding rework.

The applicability boundary is also straightforward: when there are few fields and the data is written completely by an internal script in one go, full-row overwrite is fine. For write APIs shared across multiple clients and maintained by multiple people, be sure to clearly mark the update semantics first, then add version control as a safety net.