如果您要为可以多种方式创建的资源建模,那么您最好如何处理?
我可以想象使用查询参数对同一资源进行POST,以区分不同的方式,例如
POST /logins?type=pwd with body { email, pwd } -> CREATED /logins/1
POST /logins?type=token with body { token } -> CREATED /logins/2
答案 0 :(得分:1)
我认为单POST /logins
就足够了。可以使用仅包含{email, pwd}
或{token}
的有效负载调用它。此端点的实现应决定我们在哪种情况下以及如何在正文上进行必要的验证后创建资源(提供电子邮件+密码或仅提供令牌)。
答案 1 :(得分:0)
我喜欢你的想法Alex。达林的解决方案确实解决了这个问题,但......
我想让我的ASP.NET控制器操作只处理一种类型的请求(模型绑定)并避免使用上帝方法。我也喜欢有两种创建(POST)对象的方法,这取决于输入(Factory),我想依赖路由。
Alex的解决方案和我的“要求”的问题是ASP.NET路由不能使用查询字符串。
现在我已经解决了这个问题:
POST /logins/pwd with body { email, pwd } -> CREATED /logins/1
POST /logins/token with body { token } -> CREATED /logins/2
我很想听听别人如何处理这个问题。
答案 2 :(得分:0)
除了在集合类型资源上使用GET之外,REST API中没有广泛使用查询字符串参数。在这种情况下,它们代表了分页,收集过滤器,搜索条件......它们表达了期望只有资源的特定部分才能作为正文。
考虑到这一点,我相信这两种模式都是完全有效的REST调用,并与当前的最佳实践保持一致。
API很可能决定支持其中一个或两个。
没有查询字符串的POST /登录
正如Darin所说,服务器可以根据内容中提供(或不提供)的字段来排序要做的事情。 服务器将验证正文的一致性并采取适当的措施。
POST /登录?type = pwd
这种形式有明显的缺点,增加了复杂性。
然而,它捕获了用户的意图,并阐明了资源的预期部分,具有一些优势: