我有一个REST API资源，可以使用多个标识符之一来获取。有时客户可能想要特定的资源，有时他们可能想要基于特定字段的一组资源。
举一个简单的例子，假设某些客户端存储了resourceId，而其他客户端存储了resourceNumber。另外，客户端可能希望获取resourceCategory等于特定值的所有资源。
我可以采用几种方法来实现这一目标，我想知道是否有最佳实践或首选一种方法。
有一条路由，例如GET /api/resource，其参数分别为resourceId，resourceNumber和resourceCategory。根据提供的参数，返回相应的资源。
有多条路线，例如
GET /api/resource/id/{resourceId} GET /api/resource/number/{resourceNumber} GET /api/resource/category/{resourceCategory}。方法1允许某人指定多个选项，这在某些情况下可能是不错的选择，但在其他情况下则没有意义（即resourceId和resourceNumber可以互斥）
我已经进行了大量的搜索并研究了OpenAPI规范（我正在遵循），但是未能找到解决此问题的任何方法。
请注意！！！ 我不是在寻求个人意见。我想遵循现有的任何最佳做法/标准，所以我要问是否存在适用于RESTful Web服务的此方案的最佳做法或标准，例如OpenAPI。
我也好奇哪种方法更常用，尽管我意识到这可能很难确定。
答案 0 :(得分：2)
我在问是否有最佳实践或标准（例如OpenAPI）涵盖了RESTful Web服务的这种情况。
REST在这里不会为您提供很多指导。
问题是这样的：为控制器选择设计是实现细节。 REST的重点是那些实现细节隐藏在统一接口的后面。
换句话说，您的RESTful Web服务的行为应类似于网站或HTTP缓存。资源标识符只是用于在缓存中查找表示形式的键。
/api/resource?resourceId={resourceId}
/api/resource?resourceNumber={resourceNumber}
就REST而言，它们是不同的资源。没有特别的理由假定它们彼此相关。客户不会认为对一个进行更改必然意味着对另一个进行了更改。
在语义上，标识符只是一个标识符，例如数据库中的代理密钥或UUID。 REST客户端不会尝试从标识符中提取含义。
REST客户端确实了解relative references的规则，因为它们是RFC 3986所描述的。因此，您可以根据点段的处理方式（路径段和查询处理方式）来选择标识符的不同拼写不同）。
某些URI拼写更易于使用，因为它们与您可以使用的URI template实现对齐。 URI模板使将信息注入标识符或稍后提取信息变得更加容易。并且模式是标准化的。
但是这些模式在语义上仍然是不可知的。
二十年前，我们需要担心的事情之一就是实现不符合标准的实现，因此您可以选择标识符拼写来避免出现问题。但是，这又是一个与语义无关的问题。
因此，剩下的实际上只是一堆人类的拼写约定，就像变量名一样，参数在很大程度上是局部上下文中的政治问题（即：您的拼写应该与程序员所选择的拼写“一致”）在旁边的桌子上。）