我们正在重新设计一些API，并且正在考虑采用REST风格的方法，但我们意识到我们不确定如何处理某些情况（具有影响所选内容的参数的资源列表等），甚至如何有效地为可能被自己引用但在概念上从属于其他实体的资源构建网址（想想用户/帖子/评论，但关系更复杂）。
我们已经看到很多关于为简单案例构建REST API的材料，但有哪些材料可以广泛讨论在更真实的场景中做出这些选择？
答案 0 :(得分：3)
首先，需要注意的是REST是架构，这意味着它只是描述了解决和使用资源所遵循的策略。它没有说明如何实施该策略，甚至没有说明如何判断某人是否具有RESTful。
我也认为你过分复杂了。以下是针对您的两个具体问题的更准确答案：
如何有效地构建资源的URL，这些资源可以由他们自己引用，但在概念上从属于某个其他实体（想想用户/帖子/评论，但关系更复杂）
即使某些事物在概念上从属于其他事物，但这并不一定是描述它的目的。例如，让我们使用您的博客示例。 Blog可能有多个Articles，每个Pictures可能有一个或多个Pictures。在第一次破解时，您可能希望能够引用http://api.example.com/articles/123/pictures/456
，例如：
Pictures但请注意，由于http://api.example.com/pictures/456
本身就是资源，所以只做以下事情没有错：
http://api.example.com/pictures?limit=500&offset=25&order=desc&by=date
（具有影响所选内容的参数的资源列表等）
在RESTful请求中包含参数是完全正常和可接受的。例如，假设您希望按照日期从第二十五张这样的图片中获得前500张图片。您的API可能支持以下内容：
{{1}}
答案 1 :(得分：1)
如果您可以更准确地提问，那么这里有很多人会尝试提供帮助。
否则，以下是一些应该有用的其他资源。
我可以给你的最好的建议是停止思考如何构建URL并关注你将在你的表示中放置什么链接。一旦找到了媒体类型，如何构建网址就很容易了。
答案 2 :(得分：0)
我会继续并假设我们正在谈论RESTful HTTP：）
这是您公开“具有影响所选内容的参数的资源列表”的方式：
/ list？{搜索部分}
搜索部分是一些任意字符串，用于定位列表资源的“部分”。
执行此操作的常用方法（浏览器+ html表单的工作方式）是为每个参数设置键/值对，即：
/列表NAME1 = fred的＆安培;名称2 = Dave和安培; NAME3 =亚光
这种排列搜索部分的惯例不是强制性的，但您会发现遵循此模式可以更轻松地为您的应用编写HTML。使用以下内容在HTTP和URI方面同样有效：
/列表？佛瑞德，戴夫，亚光
如何有效地构建网址 可能被引用的资源 他们自己，但在概念上 从属于其他实体
在REST中，没有“结构化”URI这样的东西。 URI只是一个唯一的标识符 - URI结构中的相似性和模式可以使组织服务器端逻辑变得更容易，并使用户能够“漂亮”地查看和弄清楚 - 但如果您正在执行REST，则以下内容之间没有任何关系：
/富
/富/酒吧
..除非你创建一个从一个到另一个的超链接的关系。这个经验法则通常被称为“超文本约束”或“HATEOAS”。
话虽如此 - '漂亮'你的URI是没有错的。请注意（如果你想'做REST'）你应该把所有东西连在一起。大多数API都会公开“嵌套资源”，如下所示：
/国家/英格兰/城市/伦敦
希望这有用： - ）