如果您正在爲可以以多種方式創建的資源建模，那麼您如何最好地處理該資源？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
這種形式具有增加的複雜性的明顯的缺點。
但是它抓住了用戶的意圖，並闡明什麼資源的一部分，預計爲體，與一對夫婦的優勢：