您会建议哪些策略来使 RESTful API “依赖于上下文”？
让我详细说明。
在我正在进行的一个项目中，我们正在公开一个资源 Team .用户可以创建自己的团队，这会导致 POST /teams对 API 的请求。该请求使用一组适用于用户创建的团队的规则进行验证。
我们还有一个管理界面，某些用户使用它来创建相同类型的 Team资源，但是这由一组略有不同的验证规则控制。
管理员可以使用我们的公共(public)或管理界面，因此验证必须基于他们的上下文，而不是用户的能力。
针对这种特定情况重新表述上述问题:我们如何以 RESTful 方式区分这两个上下文？即使“结果”属于同一类型，我们是否会创建两个不同的资源，如果是，您会建议什么命名约定？
最佳答案
REST 中没有任何东西可以保证资源对不同客户端的行为相同。此外，由于授权信息附加到每个请求，资源自然会对其进行分析并将特定于客户端的逻辑应用于请求。
但!如果您的资源上的某些操作引入了复杂的资源不变量，这些资源的各个部分具有依赖的生命周期，您最好尽早将其重构为更小的资源。例如，如果管理员应该添加 member到team然后一个RegularUser应该填写member的详细信息在 team ...您可能已经注意到，有两个资源 - team和 member .
提示:在分解参与不同操作的复杂资源时，您可以通过想象不同客户端引起的 future 扩展问题来获得新的想法。如果您将被资源的一个客户淹没怎么办，您将如何为另一个客户实现稳定的回复？扩展不同资源比扩展一个资源的不同部分更容易，因此请查看您的操作并考虑扩展。
关于rest - 上下文相关的 REST API 策略，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/43369508/