命令服务器的“Restful”方式是什么？

问题描述

我有一个 REST 端点来创建这样的应用程序配置

POST /applications

有身体

{
    "appName" : "my-new-app"
}

我返回一个新创建的应用程序配置：

{
  "appName": "my-new-app","appId": "2ed17ff700664dad9bb32e400d39dc68","apiKey": "$2a$10$XVDH9F3Ix4lx2LdxeJ4ZOe7H.bw/Me5qAmaIGF.95lUgkerfTG7NW","masterKey": "$2a$10$XVDH9F3Ix4lx2LdxeJ4ZOeSZLR1hVSXk2We/DqQahyOFFY6nOfbHS","dateCreated": "2021-03-28T11:00:07.340+00:00","dateUpdated": "2021-03-28T11:00:07.340+00:00"
}

注意：密钥在服务器中自动生成，而不是从客户端传递。

我的问题是，命令服务器的 RESTful 方式是什么来重置密钥，例如：

PUT /applications/my-new-app/update_keys 不是基于名词的，因此，不是restful，将命令作为查询参数传递似乎也不是restful，因为这不是 GET 方法，而是 PUT（更新）方法。

解决方法

这是发送命令的一种方式，尽可能 RESTful：

端点：

POST /application/:appName/actions

示例有效负载：

{
    "actions" : [
      {
        "action" : "name_of_command","arguments" : {
          "arg1" : "param1"
        }
      },{
        "action" : "reset_keys","arguments" : {
        }
      }
    ]
}

动作将是作为端点一部分的名词，服务器将处理在端点内提交（或发布）的动作。一组动作最适合允许发送多个动作。每个有参数的动作对于需要参数的未来动作也是可取的。

命令服务器重置密钥的 RESTful 方式是什么，例如：

您将如何通过网站实现这一目标？

你会看到一些像 /www/applications/my-new-app 这样的网页；在数据或元数据中，您会找到一个链接。按照该链接将带您进入一个表格；除了任何“隐藏的”输入之外，该表单还将具有描述您需要提供哪些字段来发送消息的输入控件。当您点击提交按钮时，您的用户代理将收集您的输入，从中构建适当的消息正文，然后使用表单元数据来确定要使用的请求方法和 uri。

客户端永远不必猜测要使用什么 URI，因为服务器会提供链接来引导。

Hypertext 是 uniform interface

的核心

REST 由四个接口约束定义：资源识别；通过表征操纵资源；自我描述信息；并且，超媒体作为应用程序状态的引擎。

因为服务器为每个链接提供 URI，所以您可以自由选择哪个资源“处理”哪个消息。

解决此问题的一种有趣方法是查看 cache invalidation 的 HTTP 规则。简短的版本是成功的不安全请求 (PATCH/POST/PUT) 使目标 uri 的表示无效。

换句话说，我们通过向我们尝试更改的资源发送命令来利用缓存失效。

因此，假设通过以下请求检索应用程序的表示：

GET /applications/my-new-app HTTP/x.y

然后我们将通过发送具有相同目标 uri 的请求来要求服务器更改该资源。类似于：

POST /applications/my-new-app HTTP/x.y
Content-Type: text/plain

Please rotate the keys

网络上的表单提交通常是键/值对的表示，因此更可能的拼写是：

POST /applications/my-new-app HTTP/x.y
Content-Type: applications/x-www-form-urlencoded

action=Please%20rotate%20the%20keys

描述此请求的表单有一个“动作”输入控件，它接受来自客户端的文本，或者在这种情况下，动作更有可能是具有预定义值的隐藏控件。

注意：如果我们有多个操作应该使 /applications/my-new-app 表示无效，我们可能会对所有这些操作使用 POST，并根据请求在服务器上解决歧义 - body（如果我们的路由框架为我们提供了所需的控制程度，我们可以使用它 - 但更常见的是为每个 Content-Type 设置一个 POST 处理程序，并“手动”解析请求正文。

POST 在 HTTP 中有许多有用的用途，包括“此操作不值得标准化”的通用目的。 -- 菲尔丁 2009

PUT /applications/my-new-app/update_keys 不是基于名词的，因此不是宁静的，

事实并非如此：REST 并不关心您对资源标识符使用什么拼写约定。例如

这些都很好，就像网络上的所有其他资源一样。

您绝对可以设计您的资源模型，以便编辑 update_keys 文档也会修改 my-new-app 文档。

潜在的困难是通用组件不会知道发生了什么。 HTTP PUT 表示“更新目标资源的表示”，每个通用组件都知道；由于“update-keys”资源的变化，源服务器被允许修改其他资源。

但是我们没有一种很好的语言来传达通用组件可能发生的所有副作用。如果没有一些特殊的魔法，以前缓存的 my-new-app 副本，带有原始的、未旋转的密钥，将被留下。因此，客户端可能会留下描述应用程序的文档的陈旧副本。

（“一些特殊的魔法”的一个例子是 Linked Cache Invalidation，它提供了使用 web linking 描述资源之间的缓存关系。不幸的是，LCI 没有被采纳为标准，你不会在 IANA registry 中找到所描述的链接关系。）

api-design hateoas

命令服务器的“Restful”方式是什么？

问题描述

解决方法

相关问答