在 RESTful API 设计中，PUT 和 PATCH 是用于更新服务器上资源的两种 HTTP 方法，但 REST API 中 PUT 与 PATCH 之间的区别在于它们执行更新的方式以及每种方法最合适的场景。这两种方法都旨在修改现有数据，但了解 REST API 中的 PUT 和 PATCH 差异可以帮助开发人员根据需要执行的更新的性质做出最佳选择。在这篇博文中，我们将探讨 REST API 中的 PUT 和 PATCH 差异，重点关注 PATCH 与更新 REST 争论、何时使用每种方法，并提供针对不同用例选择正确方法的指导。
REST API 中的 PUT 是什么？
要了解 REST API 中 PUT 与 PATCH 之间的区别，首先我们需要知道 PUT 是什么。基于 RFC 2616 第 9.6 节，REST API 中的 PUT 方法请求将所包含的实体存储在提供的 Request-URI 下。
如果 Request-URI 引用一个已经存在的资源，则所包含的实体应该被视为驻留在源服务器上的实体的修改版本。如果请求 URI 不指向现有资源，并且该 URI 能够被发出请求的用户代理定义为新资源，则源服务器可以使用该 URI 创建资源。
换句话说，PUT 方法用于更新服务器上的整个资源。这使得 PUT 成为更“完整”的更新，通常在需要完全替换资源时使用。
因此，PUT 最适合以下用例：
- 更新完整的资源（例如，使用所有新信息更新用户配置文件）。
- 替换整个项目或记录。
- 当资源的身份明确，并且其数据需要完全刷新时。
在像这样的系统中 弹性搜索，幂等操作是保证数据一致性所必需的。例如，使用 PUT 更新 Elasticsearch 中的文档可确保可以重复相同的请求，而不会产生意外的副作用。
REST API 中的 PATCH 是什么？
现在我们已经介绍了 REST API 中的 PUT，在比较 REST API 中的 PUT 与 PATCH 之前，让我们先看看 REST API 中的 PATCH 是什么以及它是如何工作的。正如定义在 RFC 5789，REST API 中的 PATCH 方法请求将请求实体中描述的一组更改应用于由 Request-URI 标识的资源。
这与 PUT 与 PATCH REST API 的区别一致，您只发送需要修改的数据，服务器将这些更改应用于现有资源，而不更改整个资源。开发人员经常创建补丁来表示这些增量更改，确保最少的数据传输和高效的更新。
这就是为什么 REST API 中的 PATCH 方法更适合以下用例：
- 仅更新资源中的部分字段（例如，更改用户的电子邮件地址或电话号码）。 PATCH API 示例可能只发送新电子邮件，而其他字段保持不变。
- 通过最小化数据负载来提高性能。
- 当您想要增量更新资源而不是完全替换它时。
- 创建补丁来封装特定字段的更改，例如修改用户的电子邮件，而不影响不相关的数据。
对于像这样的平台 无头CMS 通常处理复杂的内容结构，使用 PATCH 进行较小的更新（例如修改单个字段）可以减少服务器负载并提高性能。
了解这两种方法后，您应该对 REST API 中的 PUT 和 PATCH 有了一个很好的了解。然而，在我们讨论 REST API 中 PUT 与 PATCH 的区别之前，我们需要先讨论一下这两种方法中的幂等性。
PUT 中的幂等性与 REST API 中的补丁
在 REST API 中，幂等性是指操作的属性，当使用相同的输入重复多次时，会产生相同的结果。这意味着多次发出相同的请求应该对服务器产生相同的效果，无论执行多少次。这对于确保 API 的稳定性和可预测性非常重要。但它与 REST API 中的 PUT 和 PATCH 差异有什么关系呢？
PUT方法和幂等性
REST API 中的 PUT 方法始终是幂等的，因为它旨在用请求中提供的数据替换指定 URI 处的整个资源。换句话说，如果您使用相同的资源数据多次执行 PUT 请求，结果将始终相同。
为什么 PUT 是幂等的？当您发出 PUT 请求时，您实际上是在告诉服务器：“这是我想要的该资源的完整且准确的状态。”无论您发出一次还是多次 PUT 请求，生成的资源始终是相同的。
例如，考虑更新用户的电子邮件地址的场景。如果多次发出相同的 PUT 请求，结果不会改变，因为每次资源都会被相同的数据替换。
例子：
| PUT /users/1{“用户名”：“john_doe”，“电子邮件”：“[email protected]”} |
如果多次发送此请求，结果将始终相同：
| {“用户名”：“john_doe”，“电子邮件”：“[email protected]”} |
即使用户的数据已经是这样，再次发送请求也不会改变任何东西。它将数据替换为相同的数据，因此无论重复多少次，请求的效果都保持不变。这就是 PUT 幂等的原因。
PATCH方法和幂等性
另一方面，REST API 中的 PATCH 方法通常也是幂等的，但具有更大的灵活性。创建补丁时，请确保操作是幂等的（例如，设置值），以避免重复请求带来的意外副作用。 PATCH是否幂等取决于操作和被修改的数据。
为什么 PATCH 是幂等的？对于 PATCH 请求，幂等性意味着多次应用相同的补丁将得到相同的结果。只要补丁本身在重复应用时不会导致额外的副作用或变化，情况就是如此。如果您继续使用相同的数据应用相同的补丁，则第一次应用后结果应该不会改变。
例如，如果您只是更新用户的电子邮件，则重复发送相同的 PATCH 请求不会改变第一次后的结果，即使多次发出请求。用户的电子邮件将保持不变，并且资源的状态不会改变。
补丁 API 示例：
| 补丁 /users/1{“email”: “[email protected]”} |
如果电子邮件已经是 [email protected]，则再次应用此 PATCH 将不会导致任何更改，从而使其具有幂等性。
但是，PATCH 在某些情况下也可以是非幂等的。例如，如果 PATCH 操作修改计数器或向列表添加项目（例如递增数字或追加到数组），则重复应用同一 PATCH 可能会导致不同的结果。这会违反幂等性。
非幂等 API REST PATCH 示例：
| 补丁 /counter/1{“增量”: 1} |
如果重复应用此 PATCH，计数器将不断增加，导致每次都有不同的值。这不是幂等的，因为结果随每个应用程序而变化。
现在您已经了解了要点，我们可以查看一些示例场景，以更好地理解 REST API 中 PUT 与 PATCH 之间的区别。
示例场景：REST API 中的 PUT 与 PATCH
抛开理论不谈，让我们通过示例来看看 PUT 和 PATCH 之间的区别，包括幂等和非幂等操作。
场景 1：PUT 请求 – 替换整个资源
想象一下用于管理电子商务系统中的产品的 API 端点。您需要更新产品的所有详细信息，包括名称、价格和描述。这是 HTTP 方法 PUT 与 PATCH 的典型示例，其中 PUT 用于替换完整的产品资源。
初始产品：
| GET /products/1001{“id”：1001，“name”：“笔记本电脑”，“price”：999.99，“description”：“功能强大的笔记本电脑。”} |
您想要更新产品的价格和描述。您发送包含整个资源的 PUT 请求：
放置请求：
| PUT /products/1001{“id”: 1001,”name”: “笔记本电脑”,”price”: 899.99,”description”: “一台打折的功能强大的笔记本电脑。”} |
如果您发出一次或多次此 PUT 请求，结果将始终相同。产品详细信息将更新以反映新的价格和描述，并且每次都会出现相同的结果。这确保了 PUT 的幂等性。
结果（PUT 请求后）：
| {“id”：1001，“name”：“笔记本电脑”，“price”：899.99，“description”：“一台打折的功能强大的笔记本电脑。”} |
场景 2：PATCH 请求 – 更新部分资源
现在，让我们考虑一个仅更新部分产品详细信息（例如描述）的 PATCH 请求。 PATCH API示例：如果您想更改产品描述而不是价格，PATCH是更好的选择。为了实现这一点，您将创建仅包含需要修改的字段的补丁，例如此 API REST PATCH 示例中的描述。
初始产品：
| GET /products/1001{“id”：1001，“name”：“笔记本电脑”，“price”：999.99，“description”：“功能强大的笔记本电脑。”} |
补丁请求：
| PATCH /products/1001{“description”：“一款轻巧、功能强大的笔记本电脑。”} |
当您发送此 PATCH 请求时，仅描述字段将被更新。如果多次发送相同的 PATCH 请求，则第一次更新后描述将保持不变，从而使请求具有幂等性。
结果（PATCH 请求后）：
| {“id”：1001，“name”：“笔记本电脑”，“price”：999.99，“description”：“一款轻巧、功能强大的笔记本电脑。”} |
如果您再次应用相同的 PATCH，产品描述仍将与第一个 PATCH 后的产品描述相同。结果是一致的，这使得 PATCH 在这种情况下具有幂等性。
场景 3：PATCH 请求 – 非幂等操作
让我们看一下非幂等的 PATCH 操作。假设用户的钱包余额有一个端点，并且您想要增加余额。 PUT 和 PATCH 之间的差异示例如下所示：PATCH 每次都会向余额添加一个值
初始钱包：
| GET /users/1/wallet{“id”: 1,“balance”: 100.00} |
补丁请求：
| 补丁 /users/1/wallet{“增量”: 50.00} |
此 PATCH 请求将使钱包余额增加 50 美元。如果您多次发送此 PATCH 请求，余额将随着每个 PATCH 不断增加，导致每次结果不同。这是非幂等的，因为重复应用相同的 PATCH 会导致不同的结果。
结果（第一次 PATCH 请求后）：
| {“id”：1，“余额”：150.00} |
结果（第二个 PATCH 请求后）：
| {“id”：1，“余额”：200.00} |
这里，PATCH 不是幂等的，因为使用相同数据的重复请求会产生不同的结果。
回顾：REST API 中 PUT 与 PATCH 之间的主要区别
REST API 中的 PUT 与 PATCH 之间的主要区别在于它们处理更新的方式。 PUT 会替换整个资源，因此任何丢失的字段都会被擦除，这可能会导致数据丢失。这就是开发人员为部分更新创建补丁的原因，以避免覆盖未更改的字段并保持数据完整性。
这使得 PATCH 对于部分更新更加有效。 PATCH API 示例是，如果您只想更新用户的电子邮件，则创建补丁只会发送电子邮件字段，这与需要整个用户数据的 PUT 请求不同。
使用 PUT 时，需要完整的数据负载。这意味着必须发送每个字段，并且任何丢失的字段都将被删除。然而，PATCH 只发送需要更新的字段，使其更加高效，特别是对于具有最小更改的大量资源。 REST API 中的 PATCH 方法允许更集中和更小的请求，从而减少数据传输。
PUT 和 PATCH 都是幂等的。这意味着重复相同的请求将导致相同的结果。然而，PUT 更可预测，因为它替换了整个资源。 PATCH 当仅用于修改指定字段时，可能会导致不同的结果，具体取决于服务器处理更新的方式。
例如，如果 PATCH 增加计数器，重复的请求可能会导致不同的结果。尽管如此，PATCH API 操作也可以设计为幂等的。
总之，REST API 中 PUT 和 PATCH 的区别归结为更新的性质：PATCH 用于部分更改，而 PUT 用于完全资源替换。两者都是幂等的，但 PATCH 可能更复杂。
最后的想法
PUT 和 PATCH 都是 REST API 设计中的基本 HTTP 方法，但它们的用途不同，这就是 REST API 中 PUT 和 PATCH 区别的本质。通过使用本文前面介绍的示例了解 PUT 和 PATCH 之间的区别，您可以显着提高 API 的效率、清晰度和功能。通过根据您的用例选择正确的方法（PATCH 与更新 REST），您可以使您的 API 更加高效、可维护且用户友好。请始终考虑更新的性质（无论是全部更新还是部分更新）以及对性能和数据完整性的影响，并选择最适合您需求的方法。
