在使用REST API时，我希望您对给定的方案有意见。
比方说，我有一条获取用户详细信息的途径，我们为supplier, buyer and admin之类的用户提供一些角色。
获取：用户详细信息/ {id}
在这种情况下，如果我们将supplier用户角色与具有角色buyer或admin的用户进行比较，则必须获取其他一些与用户相关的数据。
我们是否可以通过发送查询参数到路由来创建如下所示的路由以获取每个用户的详细信息，如：
获取：用户/ 1 /供应商
获取：用户/ 1 /买家
---或---
获取：用户/ 1？role =供应商
如果我们为每条路线引入不同的功能，这将降低复杂性，并且可以轻松调整针对特定user role的任何更改请求。
答案 0 :(得分：1)
设计路由完全取决于您返回给客户端的数据类型以及要为每个用户角色实现的业务逻辑类型。但不希望将用户角色传递到查询字符串中。
如果要为每个角色返回不同的数据，并且您有一些业务逻辑，则最好为每个用户角色定义不同的路由。
GET: users/1/supplier
GET: users/1/buyer
如果您没有那么多的业务逻辑，但是希望使用其他条件来检索相同的数据（想在基于用户角色的条件下动态添加SQL），则可以使用laravel雄辩的方式获取结果{{ 1}}，即使您不需要定义多个路由。
答案 1 :(得分：1)
如果用户角色不重叠，即供应商永远不会是买方，而买方永远不会是供应商，那么：
我们可以通过API方法中的ID获得用户角色，并可以创建不同的方法来获取不同组用户数据的详细信息（基于“类型”-使用Switch，可能是） 单个API支持所有用户类型就可以了：GET：user-details / {id}
但是，如果供应商也可以充当买方，那么您应该具有不同的功能/路线设置。
例如供应商详细信息/ {id}或买方详细信息/ {id}
采用不同的途径侧重于仅针对用户类型提供特定数据。
答案 2 :(得分：0)
我们可以通过发送查询参数到路由来获取每个用户的详细信息来创建如下所示的路由
是的，您可以-创建新的资源来处理新的用例是一件很合理的事情。
需要权衡取舍。就“ REST”客户端而言，两个不同的URI意味着两个不同的 unrelated 资源-即使它们碰巧具有重叠的路径段。这意味着invalidating一种资源的缓存表示形式不会以任何方式影响另一种资源。因此，您可以得到一个客户端，该客户端已缓存了彼此不一致的两种资源的表示形式。
要考虑的另一种方法是，您要拥有两个资源，还是一个具有两个表示形式的资源。具有相同资源的多个表示形式可以解决缓存失效的问题，但是您将额外的复杂性移到了分配多种媒体类型的知识这一问题上。
答案 3 :(得分：-2)
如果“供应商”和“买方”是用户的子资源，那么第一种方法就可以了。
在第二种情况下，“ role =供应商”看起来更像是一个搜索条件。