如何處理牛仔REST處理程序的錯誤消息的媒體類型

我希望用戶有機會選擇它從服務器接收響應的格式，無論它是純文本，json還是xml 。看起來我必須通過調用cowboy_req：meta/{2,3}來檢索media_type，然後將其用於對響應主體進行編碼。但是在content_types_provided（malformed_request，is_authorized，forbidden ...）之前的回調中，該值不可用。如何處理牛仔REST處理程序的錯誤消息的媒體類型

我應該公佈一個牛仔邏輯並編寫自己的代碼來確定media_type嗎？

或者忽略已經確定media_type之前執行的所有回調。

或者我應該將我的響應消息放入請求元數據並在響應掛鉤中進行編碼，然後替換響應體？

我該怎麼做？

來源

2014-04-01 boxx

我經常做出一個艱難的決定：「所有狀態碼響應主體將是文本/純文本」（或application/json）。這更容易管理。 –

我覺得你不太好。直接從init/3和rest_init/3函數Request參數是「完整請求」，並且您可以在每個回調中讀取任何標題或元。

並且我個人會在Meta上使用Header（因爲已經定義了Content-Type標題，並且標題應該超過Meta）。

一般來說，牛仔中的REST回調應該只給你一個容易理解的處理請求的工作流程，並附加默認的響應代碼。在is_authorized/2所有你需要做的就是檢查授權，只需返回true或false（作爲元組的一部分），牛仔會隨着你的邏輯前進或返回401代碼。檢查是允許請求的人不應該根據響應格式來確定，但是，如果您想要這樣做，只需從Req參數中讀取此元數據，並根據它返回true/false。

與content_types_provided/2唯一的區別在於，您返回Content-Types標頭值與您的函數之間的某種綁定。我認爲你所需要的全部都可以基於此official example

來源

2014-04-01 14:24:25 mpm

在我的情況下，我想在每個請求中返回一個帶有人類可讀消息的響應主體。當然，我可以忽略請求的meta並僅使用標題。在這種情況下，我需要讀取Accept頭的值，然後將它與content_types_provided列表進行比較，最後我會知道響應正文的正確格式。所有這些邏輯已經在牛仔代碼中定義了，因此我正在尋找一種不重新實現它的方法。 – boxx

如何處理牛仔REST處理程序的錯誤消息的媒體類型

回答

相關問題