在前面的一篇博客中，我们已经学习了实现诸如CREATE和UPDATE之类的写操作的基础知识在本博客中，我们将讨论一些更高级的细节：更新操作可以通过PUT或PATCH请求发出，请参见下面的区别一个更新操作可以附带一个"prefere"标题，它有一些影响，请继续阅读以了解影响。
哦-顺便说一下-这个博客是关于用Java创建ODataV4服务，人工智能知识体系，使用SAP云平台SDK进行服务开发。这里有一个介绍，这里有一个博客系列的概述
为了简化起见，行业大数据分析，SDK中只有一个注解可以启用回调更新操作。但是，有两个HTTP动词用于发出更新：PUT请求和PATCH请求在这两种情况下，SDK都会将请求重定向到我们的实现方法，并用@Update注释。在这里，我们可以从UpdateRequest实例中获取请求主体，然后处理数据源中的更改PUT和PATCH有什么区别？
示例：
在我们的人员集合中，我们存储了一个同时更改了电子邮件地址的人员。没问题，我们有一个很好的OData服务，我们可以很容易地更新存储的数据。我们做一个查询操作来获得完整的列表，然后我们找到我们想要更改的Person条目，然后我们对单个条目做一个READ请求好吧，我们看到错误的电子邮件地址，其他一切都是正确的。因此，我们只想更改一个属性，电子邮件。所以我们准备一个HTTP请求，只发送请求体中的一个属性，然后选择HTTP动词作为补丁。发送请求。因此，只有电子邮件会更改，而此人的其他数据将保持不变。
这意味着，在使用修补程序请求时，只有请求正文中发送的那些属性必须更改，其他所有属性都不会被触及。
我们可以用PUT做同样的操作。但是在这种情况下，我们必须从单个用户的READ请求中复制所有属性。然后发送所有的属性，不仅是更改后的Email属性，还有一个PUT请求。
PATCH的一个优点很明显：网络流量小得多。
顺便说一句，odatav4规范建议使用PATCH。您可能希望查看V4部分的新增功能。
顺便说一句，OData V2中已经支持修补程序
我们已经提到了相关细节：我们服务的用户只发送他想要更改的属性。他不关心生成的值，不可编辑的值，等等更多信息可以在规范中找到
这里我们要处理两个额外的细节：
想象一下，用户只发送Email属性，没有其他内容，而是使用PUT请求而不是补丁。
后端会发生什么？
答案可以在我上面链接的相同规范中找到： open.org/odata/odata/v4.0/errata03/os/complete/part1 protocol/odata-v4.0-errata03-os-part1-protocol-complete.html#
规格明确：缺少的属性必须重新设置。
这意味着–在我们的示例中–如果用户在PUT请求中仅发送电子邮件属性，则只有电子邮件将更新为新值，所有其他（缺少的）属性（如名称等）将设置为空。
但是：如果有默认值，则缺少的属性将重新设置为其默认值值。
和：如果一个属性被声明为不可为null：那么它永远不能为null。因此，要么它必须出现在请求主体中，要么它的值是在服务实现中生成的
：当然，key属性无论如何都不能更改。在这两种情况下，PUT和PATCH，key属性都可以从请求体中省略
有一些更高级的细节，我们不想在这里讨论，但是可以通过同样的链接在同一个规范中找到
我们的博客是初学者的教程，都是关于Java代码的。所以我们不能错过这个博客。有人常说，没有代码的博客就像没有笑话的谈话……
不过，在这种情况下，我想指出，我们要讨论的代码是为了澄清，我希望在生产性服务中不需要编写这样的代码。
我想用它来展示处理属性之间的区别。事实上，使用SDK，开发者不需要区分用户使用的HTTP动词。
说到这里，我们可以继续做，得到HTTP动词以便区分：
补丁
如果是补丁，我们只需循环负载中的所有属性。缺少的属性可以忽略。我们只需要处理不应该修改的密钥属性
我想说：那已经是它了。
现在放：
这里我们要考虑不同的情况，如上所述：
请在本页末尾找到完整的源代码。但别忘了：这只是一个包含许多ifs和else的综合代码，用于分别处理每个属性。这只是为了更好的理解。
谈论源代码：我在附录部分添加了一个替代的示例实现。
如果您熟悉OData V2，那么您知道成功的PUT或补丁请求总是返回一个状态代码为204的空响应–没有内容。
在这方面，OData V4规格更灵活。它说：
是的，这是非常灵活的。
这就是"首选"头进入游戏的地方。
通过添加带有以下值之一的"首选"头，用户可以影响响应行为。
对于PUT/PATCH请求，以下两个首选头值对成功响应有影响：
OData V4规范给出所有细节
因此，大数据分析应用，在PUT/PATCH的情况下，我们可以说：
