我目前正在通过 http 添加 REST API 到在线服务，我遇到了一个非常简单的问题，我找不到令我满意的答案：
我主要有 2 个资源：“用户”和“报告”，正如您所猜测的那样，报告与用户相关联（与一个且仅一个，=我的数据库中的外键）
不管怎样，我有这个 url 映射GET :
-
mywebsite/api/users/{id}：返回用户及相关信息，如果 id 不存在则返回用户列表
-
mywebsite/api/report/{id}：返回报告和相关信息，如果 id 不存在，则返回报告列表
现在我想获取特定用户的报告，我现在的做法是向GET报告方法：?username={username}如果存在，我将过滤结果以仅返回该用户的报告。
我忍不住认为有些事情是错误的......如果我开始做这样的事情，我将有我的方法处理GET充满了 if/else 寻找缺失的参数...
我想到的其他解决方案是：
- 将报告纳入结果中
GET on mywebsite/api/users/{id}但我有很多很多的报告，所以最终它会变得非常糟糕......
- 专门为此功能映射另一个网址，但感觉不太对......
我刚刚掌握了 REST 的概念，我喜欢这个概念，但对这个问题的一些解释确实可以帮助我更好地理解它。
Thanks
Edit:
看来我遇到了 REST 世界中的一个常见问题，我将我的资源与模型绑定在一起。如果将资源与模型绑定，您最终会在聚合属性方面遇到麻烦。
有人在这里描述了这个错误http://jacobian.org/writing/rest-worst-practices/ http://jacobian.org/writing/rest-worst-practices/但我还不明白如何按照他所说的那样进行管理......
仅供参考，我正在使用 django/piston，但无论任何语言如何，这个问题都应该可以回答。
我不禁觉得有些不对劲……
您做错的唯一一件事是认为您的 URI 结构使您的应用程序或多或少是 RESTful 的。这原始 REST 文献 http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm从来没有说查询字符串不好。人们往往对 URI 结构很着迷，并且似乎认为您的 URI 必须以某种方式构建才能被视为 RESTful。使用起来没有什么问题?username=<username>. URI 只是一个 ID （尽管有些可能比其他的更人性化）.
底线：不要纠结于你的 URI 如何look。还有很多更重要的事情需要关注（促进超链接/超媒体、坚持统一的接口 - 通常是 HTTP、可缓存性等）。
这可能是一个很大的题外话，但是，至于您对资源与模型耦合的评论，您仍然没问题。如果您确实选择了 /reports/ID/user 路线，只需将“user”视为报告模型上的关系名称即可。当然，您的模型定义了报表和用户之间的关系。您可以只解析 URI 的最后部分，使其与此关系的名称匹配。在像您描述的一对一关系的情况下，设置内容-位置 http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.14标头以匹配用户的规范 URI。
例如。假设报告 123 属于用户 1。现在您有两种方式引用该用户：
http://example.com/reports/123/user
http://example.com/user/1
对于第一个 URI，设置也是一个好主意Content-Location: http://example.com/user/1 header
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
