表示REST URI中的动作（动词）

我要为客户文件执行打印操作。我还需要执行其他标准操作，例如添加，更新，删除。因此，我有以下内容：

• 对于创建新客户：
  URI = / customer / {id}，键入= POST，方法名= CreateCustomer（）
• 要更新：
  URI：/ customer / {id}，类型= PUT，方法= UpdateCstomer（）
• 对于删除客户：
  URI = / customer / {id}，键入= DELETE，方法名= DeleteCustomer（）
• 对于视图：
  URI：/ customer / {id}，键入= GET，方法= GetCustomer（）

现在，如果需要为该客户打印文档，则需要打印功能。我的URI可能看起来像这样：/ customer / {id}，类型= POST，方法= PrintCustomer（）。但是我已经将URI和POST类型用于CreateCustomer。我希望URI看起来像这样：/ customer / Print / {id}，键入= POST，方法= PrintCustomer（）。

但是我的URI中不能包含“ Print”动词。最好的方法是什么？我考虑将/ customer / document / {id}作为URI ...，但是我将遇到相同的问题。我将在“文档”上进行CRUD操作。因此，我再次用尽了用于“打印”的内容。请指教。

POST不代表“创建”，而是“过程”。您可以通过将适当的请求发布到现有资源/customers来创建新资源（即发布以创建新客户）。但是，您也可以使用POST来填充所有其他与整齐的CRUD范例不对应的动作。

在打印的情况下，您应该将打印操作视为资源本身。您要系统为您创建一个“打印作业”。这意味着您可以拥有一个prints/资源，用作所有请求的打印的容器。当您要打印某些POST内容时，请向该资源发送文档，其中包含有关要创建的打印输出的所有信息，并通过指向它们的链接来标识要打印的资源。

作为JSON文档，它可能如下所示：

{
   contents: ["http://site/customers/12345"],
   paper-size: "A4",
   duplex: "true"
}

显然，您需要对此进行自定义以使其与您要执行的操作相关。关键是要通过指定其他资源的URL来标识要打印的其他资源。

响应请求，您可以简单地返回a 200 OK或a 204 No-Content并将其视为即发即弃过程。但是，如果要增强它，可以返回201 Created并指定新创建的打印作业的URL，例如/prints/12345。

然后，用户可以GET在资源上执行，以查看其打印作业的状态（待处理，进行中等），或可以通过发出来要求取消该作业DELETE。

一旦用资源重新表述了问题，RESTful设计就应该自然而然地出现，并为您提供机会，以您可能没有立即考虑的方式进行扩展和增强。

我以前做过 要打印文档，我只返回资源的pdf版本。客户端只需要使用Accept标头application / pdf发送对资源的GET请求。

这也避免了为临时资源（如打印作业）创建新的URI。使用HTTP标头也是REST的一部分，它可以使URI保持整洁。

只需在当前URI的GET中添加一个参数

使用URI进行多个操作是非常典型的。

如果您在谈论相同的资源，但动作不同，则可以将其定义为参数。

/ customer / {id}？print = true

然后，在定义GET方法的位置检测到print参数的存在，并以不同的方式处理它。

REST是通过以下方式定义的：

• POST-创建记录，资产或资源
• PUT-更新，记录，资产或资源
• 删除-删除记录，资产或资源

另一方面，GET打算以多种方式使用，因为通常可以以多种不同形式检索资源。这就是为什么GET请求表示为查询字符串的原因。如果您使用的是数据库资源，则实际上是通过查询来检索视图，但是REST被故意抽象到更高的级别，因为REST被设计为处理许多不同类型的资源。

REST规范是相当有远见的，即使API只是最近才开始大量使用它。

如果您有兴趣了解有关REST协议的更多信息，强烈建议您阅读“ Haters Gonna Hate HATEOAS ”。

更新：

@Shauna指出了我推理中的一个有趣的漏洞。没有真正正确的方法，许多形式都可以接受。我考虑了一下，由于您的预期用途是将数据转换为其他表示形式，因此将转换定义为新的MIME类型是有意义的。

例如，您可以将URI表示为：

/customer/{id}+print

您可以在其中将响应的Content-Type设置为text / html + print。这样，将来您还可以选择定义更多的转换。

例如：

// for application/json
/customer/{id}+json

// for application/atom+xml
/customer/{id}+atom

无论哪种方式，所有形式都是可以接受的。您决定的实现方式更多地取决于个人喜好和服务器的功能。

旁白：让我澄清一下，因为似乎有些混乱。“打印”查询参数和/或内容类型用于指定如何转换资源。不是如何触发物理打印作业。出于安全原因，硬件级别的访问始终留给用户/客户端/浏览器。