2014-09-29 85 views
0

對於一個僅API的應用程序,我想驗證一個before_action傳入的HTTP請求,例如:適當的方式來響應不支持的HTTP請求?

# Returns a 405 status for unsupported HTTP methods. 
def verify_post_request 
    head :method_not_allowed unless request.post? 
end 

但我不喜歡不必創建額外的途徑來處理每一個不受支持的HTTP方法。沒有額外的路線,應用程序返回404不支持的請求,因爲找不到匹配的路線。擁有所有這些額外的「未使用」路線就像是一種代碼味道。

這裏最好的做法是什麼?它是更好地

  • 有你支持支持的方法途徑,以及404否則
  • 對所有方法路由,以便不支持的人有更多的信息響應405

前者似乎是更好維護者(更簡潔的代碼),而後者似乎對用戶更好(描述性反饋)。

+0

我看不出有任何理由這樣做。這是額外的工作或者不屬於應用程序的部分。如果我在我的路由中定義了'resource:user',爲什麼我還想要20多行定義所有請求類型和由'resource'隱式定義的路徑的其他組合? – Jon 2014-09-29 14:05:55

+0

@Jon,有其他HTTP方法的路由允許您返回更準確的響應IMO。例如,如果有人使用PUT而不是PATCH發出請求,則您的應用可以使用更多信息405「不支持的方法」而不是404「未找到」來回應。 根據行數,您不一定需要更多的行,具體取決於您的路線。例如。通過:[:get,:post]'vs'match'/ foo/bar/action',將'match'/ foo/bar/action'改爲:'foo/bar#action'行動',通過:: all' – Dennis 2014-09-29 14:11:45

+1

我寫了類似20 RoR應用程序。這從來沒有重要。如果有人使用錯誤的HTTP方法,那麼他們會在你的應用程序中做一些奇怪或錯誤的事情,而且沒有理由去迎合他們。我知道這聽起來很刺耳,但只要用戶使用您的鏈接和表單,並且您已經正確配置並測試了覆蓋範圍,以確保 - 換句話說,一個正常的應用程序 - 它不會爲您的用戶的體驗添加任何內容如果他們試圖以某種方式使用錯誤的動詞來訪問頁面,那麼給他們更詳細的錯誤。 – 2014-09-29 14:23:31

回答

3

我會去爲您支持的方法和404路線,否則。
我認爲你的應用程序應該只響應它需要的路線,並離開其他路線。

沒有必要提供更多的信息反饋。不存在的路線是404路線,僅此而已。

+0

我想向讀者指出,在我編輯澄清它是一個僅限API的應用程序之前添加了這個答案。這是我偶然遺漏的一個非常重要的區別。這意味着由於反饋數量有限,響應代碼更重要。這就是說,我沒有贊成這個答案,因爲我覺得它缺乏一個論點。你爲什麼認爲沒有必要提供更多的信息反饋? – Dennis 2014-09-29 23:33:13

+0

指定路線的事情之一是http動詞。 'POST/user/1'與'GET/user/1'不同。假設你只有'POST/user /:id'和一個用戶點擊'GET/user/1'(API,瀏覽器等)。由於您沒有'GET/user /:id',所以路由不存在並且找不到,應該是404。 – 2014-09-30 14:10:45

相關問題