基于REST的URL用于复杂资源标识符

Question

我正在尝试为需要使用复杂资源标识符的REST API构建URL

e.g。获取特定课程

GET /Courses/{id}

其中{id} = {TermId} / {SubjectId} / {SectionID}

可以接受如下格式化或者有更好的方法吗？

/课程/ {TermId} / {SubjectId} / {sectionId}的版本

Answer 1

这是不可接受的，因为它会给使用您提供的API的客户造成混淆。基本上/（斜杠）表示新资源。在这种特殊情况下，您拥有Courses个资源，其中包含TermId的特定资源，而SubjectId依次为-，依此类推。这是不可读的，而不是客户期望的。我在这里看到两种可能的解决方案：

1. 使用组合密钥，以GET /Courses/{TermId}-{SubjectId}-{SectionID} 或其他URI可用符号分隔：

   GET /Courses/{courseId}/Terms/{termId}/subjects/{subjectId}/sections/{sectionId}
   

   只需解析服务器端的密钥。

2. 使用其他URI

   cat /proc/sys/fs/inotify/max_user_watches
   

还有其他想法，你建议的那些想法似乎没用。

Answer 2

在我看来，你有两个合理的选择：

1. 使用复合键，如@Opal所说
2. 使用代理键（与您的三个唯一约束无关的任意键）

（1）的优点是URI是人类可攻击的 - 假设用户记住了将值放入的顺序以及可以有效的值。如果一个重要的用例是学生使用这些URI在线查找课程，他们可能希望跳过搜索步骤，如果他们拥有所有相关信息并只是将这些值打入URI。如果您的回复类型是HTML，这不是不合理的。

（2）的优势在于它不人类可攻击 - REST是通过超媒体发现的。如果响应类型是JSON或XML，则人类不会直接使用这些URI。

我建议支持以下端点：

GET /courses?termId={}&subjectId={}&sectionId={}
// all three parameters are optional. returns all courses that match the
// specified criteria - either a subset of the data or the full course
// data for each result

GET /courses/{courseId}