如果您正在为可以以多种方式创建的资源建模，那么您如何最好地处理该资源？REST：创建相同资源的多种方式
我能想象做POST到相同的资源与查询参数区分不同的方式，像
POST /logins?type=pwd with body { email, pwd } -> CREATED /logins/1
POST /logins?type=token with body { token } -> CREATED /logins/2
我认为一个POST /logins应该够了。它可以使用仅包含{email, pwd}或{token}的有效载荷进行调用。这个端点的实现应该决定在哪种情况下，我们是如何以及如何在对主体进行必要验证之后创建资源（仅提供email + pwd或token）。
我喜欢你的想法Alex。达林的解决方案确实解决了这个问题，但...
我想保持我的ASP.NET控制器动作只处理一种类型的请求（模型绑定），并避免上帝的方法。我也喜欢根据输入（Factory）创建（POST）对象的两种方法，我想依靠路由。
Alex的解决方案和我的“要求”的问题是，ASP.NET路由不能使用查询字符串。
现在我已经看中了这个：
POST /logins/pwd with body { email, pwd } -> CREATED /logins/1
POST /logins/token with body { token } -> CREATED /logins/2
我很想听听你对的方式来处理这个人的想法。
查询字符串参数未在REST API中广泛使用，除了在集合类型资源上使用GET。在这种情况下，它们代表分页，收集过滤器，搜索条件等内容......它们表达了期望只有资源的特定部分被预期为正文。
考虑到这一点，我相信这两种模式都是完全有效的REST调用，并与当前的最佳实践保持一致。
API可能会很好地决定支持一个或另一个或两个。
POST /登录没有查询字符串
正如达林说，服务器可以梳理一下根据在内容提供（或没有）领域做。 服务器将验证身体的一致性并采取适当的行动。
POST /登录？类型= PWD
这种形式具有增加的复杂性的明显的缺点。
但是它抓住了用户的意图，并阐明什么资源的一部分，预计为体，与一对夫妇的优势：