http - REST 设计 : what verb and resource name to use for a filtering service

Question

我正在开发一个清理/过滤服务，它有一个方法可以接收在 xml 中序列化的对象列表，并应用一些过滤规则来返回这些对象的一个​​子集。

1. 在 REST-ful 服务中，我应该为这样的方法使用什么动词？我认为 GET 是一个自然的选择，但我必须将序列化的 XML 放在请求的正文中，这有效但感觉不正确。其他动词在语义上似乎不合适。

2. 定义服务接口(interface)的好方法是什么？将资源命名为/Cleanup 或/Filter 似乎很奇怪，主要是因为在我在网上看到的示例中，它始终是一个名称，而不是用于资源名称的动词。

3. 我是否认为 REST 服务更适合 CRUD 操作并且您开始在这种服务的情况下违反规则？如果是，那么我是否做出了错误的架构选择。

4. 为了简单起见，我已经插入以 REST-ful 风格(而不是 SOAP)开发此服务，但这种尴尬的情况发生了很多，让我觉得我错过了什么。是在不应该使用 REST 的地方选择了 REST，还是可能过度考虑了一些无关紧要的东西？在那种情况下，真正重要的是什么？

Answer 1

REST 旨在按照设计的方式使用 HTTP。要成为 RESTful 考虑(标题是 REST 设计 :):

• URL 应该是资源的永久链接(缓存优势、存储/共享端点等...)
• 因为它们是资源的永久链接，所以在 URL 中包含动词表明您走错了路(过滤器是一个动词)。
• 资源集合可以是端点/foos。
• 如果您想过滤资源集合，请考虑查询字符串参数，如 ?filter= 或类似 ?ids=1,2,3,4,5 的参数。
• GET 不应更改资源。请注意，“清理”意味着某些内容将被删除，因此在执行 GET 时要小心对资源的更改。 REST 表示 GET 不应该改变资源。想象一个缓存服务器将您的清理请求作为 GET 并返回 OK，因为 t 已被缓存。缓存服务器知道不缓存 POST、DELETE 等...(这就是 HTTP 的设计方式)。
• 不排除多次​​调用 - 例如，您可以执行 get 过滤并获取一组资源进行清理，然后可以进行多次或一次 DELETE 动词调用以进行清理。
• 有时会有像事务或“工作”这样的临时资源，可以像清理一样工作。不要排除正文包含要清理的项目的资源的 POST，它会返回一个作业 ID。然后，您可以查询 jobid 以了解清理进度或状态。

很难给出准确的指导，因为问题不明确，但希望上面的 RESTful 原则指导和想法能让您走上正确的道路。如果您澄清确切的调用，我会尝试并推荐 API。

那么，假设您想清理重复的 foo。

[GET]/foos/duplicates(或/foos?filter=duplicates)

返回一个主体，其中包含重复的 foos 标识。假设返回 1,2,5(可能是名字)。

然后你可以发出:

[DELETE]/foos 正文是包含 1,2,5(或唯一名称)的数组。 delete 调用是被动的，因此即使根据 REST 原则缓存 GET 调用也没有问题。

不通过 REST 路由(例如 POX 或 JOSN RPC over http)也是可能且有效的，但此时才意识到它不是 REST。这很好，但您没有获得菲尔丁论文中描述的 REST 的好处。

http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

另外，请阅读:

http://blog.steveklabnik.com/posts/2011-07-03-nobody-understands-rest-or-http

编辑:

在阅读了您澄清的评论后，您向服务器发送了一组对象(不是持久化的服务器端)，并且它返回了过滤掉欺骗的子集(如服务器端辅助函数)，一些选项是:

1. 如果可能，请在客户端/浏览器端执行此操作 - 为什么要进行网络往返以从集合中过滤掉重复项？
2. 如果由于某种原因只有服务器有特定的知识/数据来确定两个项目在功能上是等价的(即使数据不完全相同)，那么考虑将数据集发布到服务器，响应主体包含唯一/过滤集。即使服务器没有持久化集合，它也会落入“临时”对象或集合中，并且服务器正在修改它。它在概念上不是服务器资源的 GET，缓存在这种情况下没有任何好处。