0

我正在创建一个 RESTful API，可以在其中添加、修改和删除“条目”。每个条目在创建时都会自动分配一个到期日期，并且会自动删除，除非在该日期之前更新。当一个条目被更新时，它只是被赋予一个较晚的到期日期（由服务器，用户不能选择到期日期）。

我的问题是，公开“更新”功能的 RESTful 方式是什么？

我想到的一些可能性（尽管它们似乎都不正确）：

  1. DELETE /api/entries/:id/expiration-date
  2. PATCH /api/entries/:id在"expirationDate": null（JSON）正文中
  3. PATCH /api/entries/:id有或没有身体
  4. PUT /api/entries/:id（基本上要求重新提交条目）

注意：目前 API 的唯一预期使用者将是我自己的客户端应用程序，但我可能会选择在未来将其公开。

4

2 回答 2

0

我的问题是，公开“更新”功能的 RESTful 方式是什么？

您将如何在网站上提供此功能？

您可能会首先通过 GET 请求查看条目的网页，该请求会将页面的当前表示加载到本地 cache.ou

当服务器判断条目符合更新条件时，网页将包含某种超媒体功能，以允许客户端触发更新协议。在这种情况下，您可能不希望这种可供性具有安全的语义，因此它将是使用 POST 方法的表单。当用户提交表单时，浏览器会创建一个 HTTP 请求，其中包含正确的元数据，并将表单数据复制到请求正文中，如 HTML 处理规则所述；请求将由服务器提交到 form.action 中指定的 URL。

URL 的拼写对用户来说很重要吗？不是真的，用户只是提交表单，URL 只是不透明的数据。间接地，它很重要，因为缓存失效语义的定义方式——如果我们打算更新应该驱逐以前缓存的网页表示，那么发布请求应该有页面本身的 URL。

类似地，Web 表单不需要在页面上 - 您可以使用不同的缓存规则将链接指向其他地方管理的表单。

以机器可读的方式做到这一点，你就拥有了一个 REST API。

PUT并PATCH以相同的基本方式工作，除了请求正文是页面本身的描述。下载 HTML，进行编辑，然后将整个新文档放入其中，或者计算一个补丁文档并发送它。

PUT 和 PATCH 非常适用于贫血域——比如文档存储；当您需要对更改进行逆向工程以找出意图时，直接使用表示会更具挑战性。

于 2019-03-28T05:21:41.447 回答
0

我会用

PUT /api/entries/id/renew

在正文中带有到期日期（或使用默认值没有到期）。原因是到期与对象本身并不真正相关；它是与系统如何管理对象相关联的元数据。

于 2019-03-28T02:50:54.353 回答