通常在设计REST API时，我会看到/resourceA/{id}/resourceThatBelongsToA的常见模式。
设计API时可以/resourceA/resourcesThatBelongToA吗？
假设我有一个类似于StackOverflow的Web应用程序。有问题，每个问题的状态为accepted或not accepted。
我公开了一个端点/questions/{id}/status，以便用户可以确定某个问题是否有接受的答案。
然后我遇到了想要发现所有已接受答案的问题的问题。然后我定义了一个端点/questions/statuses?status=accepted。当没有给出查询参数时，该端点将列出所有问题的所有状态（对状态返回量的合理限制，比如说100）。但是，当给出状态类型的过滤器时，我可以确定所有具有已接受答案的问题。
对我而言，这似乎是一个很好地适应用例的实用设计。
这是一种可以使用的模式还是有更适合的模式？
答案 0 :(得分：1)
当您拥有要处理的父资源的唯一ID时，REST API看起来很好。如果您想获取具有特定ID的问题资源，/questions/{id}会很好。但是，如果您没有唯一的ID，并且响应将是一组资源，那么它只是应用于父资源的过滤器。
因此，对于您的情况，API可以是
/questions?status=accepted
如果您希望api消费者能够灵活选择限制，则可以使用查询参数限制。
/questions?status=accepted&limit=10
答案 1 :(得分：1)
在设计API时可以/ resourceA / resourcesThatBelongToA吗？
是
REST并不关心您用于标识符的拼写。 REST并不关心如何组织资源层次结构。
这是一种可以使用的模式还是有更适合的模式？
我推荐的启发式是＆＃34;你会用网站这样做吗？＆＃34;如果答案是肯定的，那么你就走在了正确的轨道上。