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}

的有效负载调用它。该端点的实现应该决定我们在哪种情况下以及在正文上进行必要的验证后如何创建资源（提供电子邮件+pwd或仅提供令牌）。

我喜欢你的想法。达林的解决方案确实解决了问题，但

我想让我的ASP.NET控制器操作只处理一种类型的请求（模型绑定），并避免使用god方法。我还喜欢根据输入（工厂）创建（发布）对象的两种方法，我想依靠路由

Alex的解决方案和我的“要求”的问题是ASP.NET路由不能使用querystring

目前，我已经确定了这一点：

POST /logins/pwd with body { email, pwd } -> CREATED /logins/1
POST /logins/token with body { token } -> CREATED /logins/2

---

我很想听听其他人关于如何处理这个问题的想法。

查询字符串参数在REST API中没有广泛使用，除了使用集合类型资源上的GET。在这种情况下，它们表示分页、集合过滤器、搜索条件。。。它们表达了一种期望，即只期望资源的特定部分作为主体

考虑到这一点，我相信这两种模式都是完全有效的REST调用，并与当前的最佳实践保持一致

一个API很可能决定支持一个或另一个，或者同时支持两个

不带查询字符串的发布/登录

正如Darin所说，服务器可以根据内容中提供（或不提供）的字段来选择要做什么。 服务器将验证正文的一致性并采取适当的操作

POST/logins？type=pwd

这种形式的明显缺点是增加了复杂性

然而，它抓住了用户的意图，并澄清了资源的哪些部分应作为主体，具有以下几个优点：

• 服务器可以提供更多相关反馈（验证消息）。例如，如果服务器作为主体{电子邮件、PWD、令牌}或{pWD、令牌}。
，服务器应该做什么？
• 它使API网关可以轻松地使用该类型进行路由、分片或断路等操作。最终，它将有助于大型基础设施的建设