筛选条件的查询字符串与资源路径

Question

• ID
• 主题
• semester_id
• 年份
• 节
• Professor_ID

教授具有以下属性：

• ID
• 教员
• super_user
• first_name
• last_name

• get/api/professors/:prof_id/cources
• 获取/API/课程？professor_id=:prof_id

但我不确定该用哪一种。

目前，我正在使用后者的扩展形式。我的推理是，如果我想添加过滤/排序标准，它更可缩放。

GET /api/courses?where={professor_id: "teacher45", year: 2016}&order={attr: "topic", sort: "asc"}

是否有使用查询字符串与资源路径进行筛选条件的标准实践？过去一些较大的API做了什么？是否可以接受或鼓励同时使用两个范例（使两个endpoint可用）？如果我确实应该使用第二个范例，那么除了对JSON进行编码之外，还有更好的组织方法可以使用吗？有没有人看到在查询字符串中使用JSON的另一个公共API？

编辑以减少意见基础。（见评论）

Answer 1

正如在前面的注释中已经解释过的，除非违反了RESTful约束或超文本传输协议(HTTP)本身，REST并不太关心标识唯一资源的链接的实际形式。

关于查询或路径（甚至矩阵）参数的使用完全取决于您。没有固定的规则，什么时候使用什么，只是个人的偏好。

我喜欢使用查询参数，特别是当值是可选的而不是必需的时候，因为很多框架（如JAX-RS）都允许定义默认值。查询参数通常被认为是为了避免缓存响应，但这更多的是一个城市传说，而不是事实，尽管某些实现仍然可能会省略包含查询字符串的URI的响应。

关于描述关系，我通常从1：N关系的1部分开始。如果我面临一个M：N关系，就像你和教授们的情况一样，我通常从一个实体开始，这个实体可能更容易地没有另一个存在。一个教授即使不举办任何讲座（在特定的学期），他仍然是一个教授。如果没有教授，课程就不可能是课程，我会把教授放在课程之前，尽管在Rest方面，课程是很好的顶级资源。

因此我将更改您的查询

GET /api/courses?where={professor_id: "teacher45", year: 2016}&order={attr: "topic", sort: "asc"}

类似于：

GET /api/professors/teacher45/courses;year=2016?sort=asc&onField=topic