你建议什么策略来使RESTful API"依赖于上下文"？
让我详细说明一下。
在我正在处理的一个项目中，我们正在公开一个资源Team。用户可以创建自己的团队，这会导致对 API 的请求POST /teams。使用一组适用于用户创建的团队的规则来验证请求。
我们还有一个管理界面，某些用户使用它来创建相同类型的Team资源，但这由一组略有不同的验证规则控制。
管理员可以使用我们的公共或管理界面，因此验证必须基于其上下文而不是用户的能力进行。
针对这种特定情况重新表述上面的问题：我们如何以 RESTful 的方式区分这两种上下文？即使"结果"属于同一类型，我们是否创建两个不同的资源，如果是，您会建议什么命名约定？
REST 中没有任何内容可以保证资源对于不同的客户端的行为相同。此外，由于授权信息附加到每个请求，因此资源自然会对其进行分析并将特定于客户端的逻辑应用于请求。
但！如果对资源的某些操作引入了复杂的资源不变量，这些不变量与资源部件的生存期相关，则最好尽早将其重构为较小的资源。例如，如果管理员应向team添加member，然后常规用户应在team中填写member的详细信息...您可能已经注意到，有两种资源 -team和member。
提示： 在分解参与不同操作的复杂资源时，可以通过想象未来不同客户端导致的伸缩问题来获得新的想法。如果您被资源的一个客户端压得喘不过气来，您将如何为另一个客户端实现稳定的回复？缩放不同的资源比缩放一个资源的不同部分更容易，因此请查看操作并考虑缩放。
我相信您应该做的是为每个管理员创建一个"用户级"令牌，或者只是为每个管理员创建一个用户，当他们需要公共接口时应该使用。
只有一个接口，即 REST API 方面的/teams，您的令牌可以决定验证规则。
或者，如果每个管理员都由一个团队负责，我会设计/admins/x/teams 端点以不同的方式进行验证，并且只接受 x 的身份验证。 子资源仍然是 RESTful。