我需要创建一个RESTful Web服务，允许使用不同类型的ID来寻址实体。我会给你一个基于书籍的例子（这不是我需要处理的，但我想以这种方式建立一个共同的理解。）
书籍可以是以下标识符：
我可以POST /api/v1/books/The%20Bible创建一本书。之后可以通过其ISBN /api/v1/books/12312312301或ID /api/v1/books/A9471IZ1来解决此书。如果我以这种方式实现它，我将需要分析发送的任何标识符并在内部转换它。
将标识符类型添加到URL是否“合法”？喜欢/api/v1/books/title/The%20Bible？
答案 0 :(得分：2)
您需要的不仅仅是检索资源，而是通过某些标准（在您的情况下，按ISBN，标题或ID）搜索资源。在这种情况下，我可以创建一个单独的/搜索功能，而不是使您的/ books端点复杂化（理想情况下，应该只按ID返回书籍）。然后，您可以使用它搜索任何字段的书籍。
例如，您将拥有：
GET /search?title=bible
GET /search?isbn=12312312301
它甚至可以轻松扩展，以便稍后添加更多字段。
答案 1 :(得分：0)
首先：RESTful URl应该只包含名词而不是动词。您可以在线找到许多最佳实践，例如：RESTful API Design: nouns are good, verbs are bad
一种方法是检测代码中的id / identifier。 正如您已经提到的那样，模式将是：
GET /api/v1/books/{id}, like /api/v1/books/12312312301 or /api/v1/books/The%20Bible
与this.lau_类似的另一种方法是使用查询参数。但我建议将查询参数添加到书籍URL（因为只有名词，没有动词）：
GET /api/v1/books?isbn=12312312301
更好的解决方案？不确定… 因为您选择“一本书按ID”（标题除外），而不是执行查询/搜索，我更喜欢第一种方法（... /书籍应该返回“书籍集”和... / books / {id}应该只返回一本书。）
但也许有人有更好的方法/想法？
编辑： 我建议避免将标识符添加到URL，它有“难闻的气味”。但这也是一种可能的方法，我在其他API中看到了很多。让我们看看我是否可以找到一些信息，如果它“好”或应该避免。
编辑2： 请参阅REST API DESIGN - Getting a resource through REST with different parameters but same url pattern和REST - supporting multiple possible identifiers