应用程序服务调用的RESTful URL约定是否正确？

我已经看到了大量关于如何为基本CRUD操作构造URL的示例，但是在讨论更多类似命令的操作或应用程序服务调用时，我看到的很少

例如，假设在我的应用程序服务中，我有一个类似RemoveOldOrders（int customerId）的调用，该调用将从系统中删除id为“customerId”的客户超过2年的任何订单。我的restful服务上的URL是什么样子的？呼叫的有效负载是什么样子的？我会使用什么HTTP方法（POST？）

我的想法是这样的：

/Customer/1/RemoveOldOrders作为POST，主体为空（customerID来自url）

在这方面有好的指导方针吗

更新：我觉得我需要澄清一下我的问题，而不是评论一篇可能重复的文章（是的，那篇文章问的基本上是同一件事，但我真的觉得这个问题没有得到很好的回答）

如果我想对资源执行操作，但该操作不符合标准HTTP谓词，该怎么办

另一个例子：我的应用程序连接到ESB，需要有一种方法强制将我的资源投影到ESB上进行处理？在我当前基于SOAP的web服务中，我有一个类似以下的方法：

ExportCustomer(int customerId)

现在，对于RESTful服务，如何在uri中表示此操作？布赖恩·凯利答案中的选项1似乎是最符合逻辑的，比如：

POST http://someapp/api/customer/1/export

或者会：

POST http://someapi/api/customer/export/1

---

更好吗？

任何时候，只要你想对“remove”这样的动词建模，你就应该考虑

DELETE

。同样，对于“创建”think

POST

（和/或可能

PUT

），对于“读取”think

GET

，对于“更新”think

PUT

（或可能

补丁

）

因此，对于“删除旧订单”的示例，您肯定应该使用

DELETE

。现在，您唯一剩下的挑战是如何确定应该删除的订单。一旦您弄明白了这一点，URI方案将与之配合到位

以下是一些选项：

删除http://your-api.com/old-orders

此处，

旧订单的含义和范围将由接收此请求的服务器确定。这使客户机不必这样做，但也消除了他们更改该范围的能力

GEThttp://your-api.com/order-query?days-早于=730

这将返回

http://your-api.com/order-query-result/{some ID}

表示一组旧约会。然后，您只需对该URI发出一个DELETE命令，即可一次性清除旧记录

与其强迫客户机记住发出这种类型的删除命令，不如提供某种

配置

资源，可以通过API对其进行操作，以设置一些字段，如

purgeRecordsOlderThanDays=730

，并让服务器以类似

cron

的方式自动为您执行。这将是我首选的方法

---

对于导出，则需要删除“export”动词，并将其替换为资源的ESB表示形式：-

• GEThttp://someapp/customer/{id}

• 响应包括一个导出链接：

  GEThttp://someapp/customer/{id}/ESB

• 获取导出链接将返回ESB表示（具有适当的内容类型）

例如，假设在我的应用程序服务中，我有一个类似 RemoveOldOrders（int customerId），它将从 对于id为“customerId”的客户，系统已使用2年以上。 我的restful服务上的URL是什么样子的？你会怎么做 通话的有效载荷是什么样子的？我会使用什么HTTP方法（POST？）

你应该读更多关于和的书

---

URL其实并不重要。重要的是，您应该拥有带有资源标识符（URL）的资源，并且必须使用统一（标准）接口（如HTTP方法调用）来操作它们。

可能重复的问题：好的，但是如果“动词”不属于“删除”、“创建”、“更新”或一个常见的HTTP操作，该怎么办？我举了一个糟糕的例子。我看到类似的帖子是在评论我的OP时提到的，我认为它是一种“资源”，但在很多情况下都不是这样。如果我的资源仍然是一个客户，但操作是非常钝的“出口到ESB”，那么你应该考虑创建一个名词的动词，这是造成你的麻烦，并采取行动，而不是。例如，要对“导出到ESB”进行建模，您可以拥有一个

ESBExporter

资源，然后您可以

POST

到该资源以执行实际的导出。

RemoveOldOrders(int customerId)
DELETE /oldOrders {customerId: id}
DELETE /customer/{id}/orders?old=true
etc...