我有一个API设计/版本难题。假设我有一个端点/api/customers，它可以获取所有客户（忽略分页）。但是有一个不同之处：如果常规user访问此端点，则他们只会得到该用户创建的客户，而没有其他人（我可以检查访问令牌和sub字段以确定谁发送了请求）。其他用例：如果admin访问此终结点，则无论获得谁，他们都应该获得所有客户。
现在我的问题是从API设计的角度来看：在API控制器本身中进行if/else角色检查是否更好，以确定我返回所有（管理员）客户还是特定（用户）客户，还是应该区别对待？用户和管理员的端点？即所有客户的admin唯一端点将为/api/admin/customers，普通用户仍然可以访问其/api/customers？
应该是相同的端点。否则，调用您的API的每个前端必须具有相同的逻辑以确定角色和端点映射。
在REST中，通常有多个资源共享相同的表示形式。
例如，学术论文的“作者的偏爱版本”是其值随时间变化的映射，而对“在X会议的论文集上发表的论文”的映射是静态的。这是两个截然不同的资源，即使它们在某个时间点都映射到相同的值。区分是必要的，以便可以独立识别和引用这两种资源。来自软件工程的一个类似示例是，当引用“最新版本”，“版本号1.2.7”或“ Orange版本附带的版本”时，分别标识了版本控制的源代码文件。 -Fielding, 2000
与该方法完全一致，您可能有一个资源可用于“所有用户”，而另一个资源可用于“由Bob创建的用户”。
麻烦的地方是您要使用same资源标识符提供不同表示形式的情况。也就是说，当爱丽丝查看“我创建的用户”时，她看到“爱丽丝创建的用户”，而鲍勃查看“我创建的用户”时，他看到“鲍勃创建的用户”。
一种可能是让“我创建的用户”重定向到适当的资源。它适用于“目的”值，当目标资源不在本地缓存中时，该值允许进行额外的往返。
在HTTP / 2中，服务器推送可能使您免于往返的麻烦。
shared caches的规则应保护您，避免将Alice对“ me”资源的观点发送给Bob，反之亦然，但是了解各种标头的含义很有用，这样您就可以避免无意中禁用这种保护。
拥有不同的资源在某些“自己读入”设置中可能是个问题，因为缓存不会知道不安全的请求已使both]资源无效。 Bob通过POST向“我创建的用户”创建了一个新用户，并且相应的缓存条目已失效...但是“所有用户”是不同的缓存键，并且不会失效。因此，如果Bob查看所有用户视图，则他可能会看到以前缓存的副本，而没有在自己的视图中看到的更改。
在某些情况下，考虑子资源可能很有意义。
/api/customers /api/customers#created-by-Alice /api/customers#created-by-Bob但是，如果您试图减少不相关数据的交换量，那么这不是一个很好的选择。