REST设计：用于过滤服务的动词和资源名称

Question

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

1. 在REST-ful服务中，我会用什么动词来表示这种方法？我认为GET是一个很自然的选择，但是我必须将序列化的XML放在请求的主体中，但有效但感觉不正确。其他动词似乎不符合语义。

2. 定义Service接口的好方法是什么？命名资源/清理或/过滤器似乎很奇怪，主要是因为在我看到的在线示例中，它总是一个名称而不是用于资源名称的动词。

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

4. 为了简单起见，我推动以REST-ful风格（而不是SOAP）开发这项服务，但这种尴尬的案例发生了很多，让我觉得我错过了一些东西。要么选择不应该使用的REST，要么可能过度思考一些不重要的东西？在那种情况下，真正重要的是什么？

Answer 1

REST就是按照设计的方式使用HTTP。要RESTful考虑（标题是REST设计:)：

• 网址应该是资源的永久链接（缓存优势，存储/共享端点等...）
• 因为它们是资源的固定链接，所以在URL中包含动词是暗示你在错误的路径上（过滤器是动词）。
• 资源集合可以是端点/ foos。
• 如果要过滤资源集合，请考虑查询字符串，如？filter =或类似的内容？ids = 1,2,3,4,5。
• GET不应该更改资源。请注意，“清理”意味着要删除的内容，因此在执行GET时要小心对资源的更改。 REST说GET不应该改变资源。想象一下，一个缓存服务器将你的清理请求作为GET并返回OK，因为缓存了。缓存服务器知道不要缓存POST，DELETE等...（这就是HTTP的设计方式）。
• 不排除多次​​调用 - 例如，您可以进行过滤并获取一组资源进行清理，然后可以执行多次或一次DELETE动词调用以进行清理。
• 有时会有像交易或“工作”这样的时态资源，可以像清理一样工作。不要排除对包含要清理的项的主体的资源的POST，并返回作业ID。然后，您可以在jobid中查询清理进度或状态。

很难给出确切的指导，因为问题不明确但希望RESTful原则上的指导和想法能让你走上正轨。如果你澄清确切的电话，我会尝试推荐API。

所以，假设您想要清理复制的foos。

[GET] / foos / duplicates（或/ foos？filter = duplicates）

返回一个标识为重复的foos的主体。假设返回1,2,5（可能是名称）。

然后你可以发出：

[DELETE] / foos，正文是一个包含1,2,5（或名称，如果唯一）的数组。删除调用是被动的，所以即使根据REST原则缓存GET调用也没关系。

也不可能通过http而不是像POX或JOSN RPC这样的REST路由，但只是意识到它不是REST。这很好，但是你没有从fielding的论文中获得REST的好处。

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

另外，请阅读：

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

编辑：

在阅读了您澄清的评论后，您正在向服务器发送一组对象（不是持久的服务器端），并且它返回带有过滤掉的dupes的子集（如服务器端辅助函数），一些选项是：< / p>

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

Answer 2

最后一个问题：真正重要的是以一种

的方式完成工作

• 正确
• 实用易于使用
• 未来的程序员（可能包括你自己）轻松维护

REST非常适合资源上的操作，其中每个URL都匹配一些可以操作的对象。它不太适合其他用途，但这些比实际规则更具指导性。其他人已经指出了最初的dissertation on REST，但值得记住的是，很少有实现是纯粹的。

如果您有多个URL来执行这些变换类型的功能，请考虑将它们放在自己的特殊URL空间中，如/api/filter和/api/transliterate等。这将有助于用户和维护人员知道某些URL不是REST，但更像是远程过程调用。将数据发布到这些URL会导致您获得某种数据。

如果您遇到特定名称，您应该列出候选人名单，喝几杯啤酒，然后从列表中选择一个。当我被困在细节上时，这就是我所做的。

SOAP是一个简洁的协议，有它的用途，但它往往非常沉重。与使用任何特定技术相比，良好的文档和一致性可能对您的新兴API更重要。