我目前正在通过 http 添加 REST API 到在线服务，我遇到了一个非常简单的问题，但我找不到令我满意的答案:
我主要有 2 个资源:“用户”和“报告”，正如您所猜测的那样，报告与用户相关联(与一个且仅一个，= 我的数据库中的外键)
无论如何，我有 GET 的 url 映射:
mywebsite/api/users/{id}:返回用户及相关信息，如果 id 不存在，则返回用户列表mywebsite/api/report/{id}:返返回告和相关信息，如果 id 不存在，则返返回告列表
现在我想获取特定用户的报告，我现在的方法是向报告的 GET 方法添加一个可选参数:?username={username } 如果它存在，我将过滤结果以仅返回该用户的报告。
我情不自禁地认为出了什么问题...如果我开始做这样的事情，我将让我的方法处理 GET 充满 if/else 寻找丢失的参数...
我想到的其他解决方案是:
- 将报告合并到
mywebsite/api/users/{id}上生成的GET中，但我有很多报告，所以最终会变得非常糟糕。 .. - 专门为此功能映射另一个网址，但感觉不太对...
我刚刚掌握了 REST 的概念，我喜欢这个概念，但对这个问题的一些解释确实可以帮助我更好地理解它。
谢谢
编辑:
看来我遇到了 REST 世界中的一个常见问题，我将我的资源绑定(bind)到了一个模型。如果将资源与模型绑定(bind)，您最终会在聚合属性方面遇到麻烦。 有人在这里描述了这个错误http://jacobian.org/writing/rest-worst-practices/但我还不明白如何按照他所说的那样进行管理......
仅供引用，我正在使用 django/piston，但无论使用任何语言，这个问题都应该是可以回答的。
最佳答案
I can't help but think something is wrong...
您做错的唯一一件事是认为您的 URI 结构使您的应用程序或多或少是 RESTful 的。 original REST literature从来没有说查询字符串不好。人们往往对 URI 结构很着迷，并且似乎认为您的 URI 必须以某种方式构建才能被视为 RESTful。使用 ?username=<username> 没有任何问题。 URI 只是一个 ID (尽管有些可能比其他的更人性化)。
底线:不要太在意 URI 外观。还有很多更重要的事情需要关注(促进超链接/超媒体、坚持统一的接口(interface) - 通常是 HTTP、可缓存性等)。
这可能是一个很大的题外话，但是，至于您对资源与模型耦合的评论，您仍然没问题。如果您确实选择了/reports/ID/user 路线，只需将“user”视为报告模型上的关系名称即可。当然，您的模型定义了报表和用户之间的关系。您可以只解析 URI 的最后部分，使其与该关系的名称匹配。在像您描述的一对一关系的情况下，设置 Content-Location 总是一个好主意。 header 以匹配用户的规范 URI。
例如。假设报告 123 属于用户 1。您现在有两种方式引用该用户:
http://example.com/reports/123/user
http://example.com/user/1
对于第一个 URI，设置 Content-Location: http://example.com/user/1 也是一个好主意。标题
关于language-agnostic - 多个资源的 REST 接口(interface)使用，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2204509/