【发布时间】：2018-06-16 00:43:19
【问题描述】：
RESTful API 应该专注于资源而不是行动。
但是，在 HTTP 上实现 RESTful 时，由于 HTTP 方法的表达能力有限，人们在 URL 的末尾添加了[action]。
例如： http://rebilly.github.io/ReDoc/#operation/findPetsByStatus
https://developers.google.com/drive/api/v3/reference/
（删除 /files/trash 并获取 /files/generateIds）
对于ID由用户定义的API，上述设计会导致冲突。
即用户创建宠物 findPetsByStatus 或文件 trash 或 generateIds。
API 设计者无法阻止这种情况发生，因为我们无法预见未来。即我们不能保留所有可能用作操作的关键字，因为产品会随着时间的推移而发展和变化。
在这种情况下，如何设计API才不会遇到这样的问题？
我想遵循 OpenAPI 规范，但他们不允许使用 /files?action=<someAction> 的 API
【问题讨论】：
-
首先，遵循 REST 架构模型的应用程序不关心 URI 设计，因为它们使用 URI（=任意令牌字符串）只是为了调用下一个可能的操作。客户端应该使用关系名称而不是分析 URI，这可以通过通用标准（协议、媒体类型……）或特定领域的“知识”来描述。这有助于服务器在不中断客户端的情况下即时更改 URI，因为它们只会调用适合特定关系名称的 URI。接下来，restful URL 与 non-restful URL 有何不同？
-
符合某些标准（例如 OpenAPI）可以实现您所描述的好处（但是要避免破坏性更改仍然不容易）。我遇到的问题是，在 OpenAPI 规范中，我找不到以支持这种情况的方式描述资源和操作的解决方案（id 由客户定义，而不是生成的 id）。
-
您可能对什么是 URI 有误解。 URI 是一个令牌字符串，它作为一个整体指向某个资源。 URI 的段不一定指向资源的祖先，因此像
www.example.org/a/b/c这样的 URI 并没有说明b是c的父级，尽管我们通常将其解释为这样，并且也这样构造内部布局.但是 REST 并不真正关心或依赖这些。您可以做的是忽略重复的 ID 或在两者之间添加一些随机值以使 URI 再次唯一。
标签： rest restful-architecture restful-url