为值对象实现 REST API 端点的最佳实践是什么？考虑由某些与 REST API 通信的 UI 管理的应用程序设置。这里的设置是值对象。在数据库中，它只是一个键值对表。在网络级别，我认为它是传输键和值的 DTO。现在，为此类值对象定义 REST 终结点的正确方法是什么？只定义/settings，POST覆盖以前的值对象(实际上是 DTO 携带的键(是否正确？
解决此问题的一种方法是考虑如何在网站上执行此操作...
我们可能会从一些资源(/settings(开始，返回键值对的html表示形式。 该表示形式还可能包括用于提交更改的表单，或者您可以改为提供指向包含表单的页面的链接。 要提交更改，用户将导航到包含表单的页面，输入新信息，然后提交表单。 浏览器的表单处理引擎将按照表单数据/元数据的描述提交请求。
对于此用例，我们正在更改服务器上的数据，因此我们将使用不安全的语义 - 也称为 POST。 目标 URI 可以是任何内容，但利用标准 HTTP 缓存行为的一种选择是将不安全的请求发送回/settings，以便在请求成功时，以前缓存的表示形式将失效。
或者，我们可以采用远程创作方法...
像以前一样，通过 GET 下载/settings 页面。然后我们将 HTML 加载到本地编辑器中，对本地副本进行更改，然后将本地副本PUT回/settings，此时服务器可以弄清楚如何使其副本看起来像我们本地编辑的副本。
如果 HTML 很大，而更改很小，我们可能会使用 PATCH 而不是 PUT。
人们可以合理地争辩说，HTML是一种表示键/值对的笨拙方式，我们宁愿使用类似application/json的东西。 对于远程创作情况，这很好 - 当我们获取服务器时，我们告诉它我们更喜欢JSON表示形式，而流程的其余部分几乎相同：在本地编辑它，将我们更新的表示的副本放回服务器，或者描述我们在补丁文档中的更改。
在我们必须担心其他人也提交对资源的更改以及丢失编辑问题的情况下，我们可能会使用条件请求 - 从 GET 响应的标头复制元数据到 PUT/PATCH 请求，以便服务器知道我们尝试替换哪个版本的资源。