我們正在使用ServiceStack(喜歡它)來開發一個項目,但需要一些幫助來解決一個奇怪的問題。在我們的項目中,我們使用輔助方法拋出或返回各種類型的帶有ErrorResponse和ResponseStatus對象的HttpError。ServiceStack不會填充錯誤響應
它遵循描述here的模式。事情是這樣的:
protected HttpError BusinessError(string summaryMessage = "Some generic validation summary.")
{
return new HttpError(HttpStatusCode.BadRequest, "MyValidationType", summaryMessage)
{
Response = new ErrorResponse
{
ResponseStatus = new ResponseStatus
{
ErrorCode = "MyValidationType",
Message = summaryMessage,
Errors = new List<ResponseError>()
},
}
};
}
在撥打服務電話,我們會使用它,像這樣:
throw BusinessError("Help I've fallen and can't get up!");
這會工作一種享受,而我們會餵它到SS-驗證JS庫呈現我們的驗證信息。工作很好。
問題是現在ServiceStack不會將任何HttpError的細節序列化到響應中。我們得到的是400狀態代碼,「MyValidationType」錯誤代碼和空JSON響應{}
的響應。
我試着玩拋出/返回錯誤和切換服務方法的返回類型爲object
等組合,但沒有什麼似乎有所作爲。說實話,我不確定我們在項目中可以改變什麼導致這種行爲。
我很感激任何意見或指針,可能會導致這種情況?
這似乎是我們的情況完全吻合。我很好奇,這個要求背後的原因是什麼?這對我來說似乎是一種限制,因爲有一系列可用於拋出/返回自定義錯誤和響應的選項,這似乎將它與我們的Response DTO結合在一起。在我的思考方式中,我們的{RequestName} Respones DTO表示一個成功的響應 - 其他所有與此有關的內容都應該由SS的異常/驗證/自定義錯誤框架來處理,以保持我們的DTO清潔。 – Martaver
@Martaver RequestResponse約定是一種將Response DTO與Request DTO相關聯的方法,它允許類型化客戶端始終預測Request的響應類型是否應該失敗。它還允許服務器控制特定服務是否應返回帶有錯誤信息的已填充ResponseStatus。 – mythz
好的,我從中得到了好處,但有時候我們會使用這種模式,而其他時候我們不會這樣做 - 可能適合直接返回實體DTO或單個實體DTO的集合...這符合在您對「限制較少的新API」的描述中概述的「純粹回覆」的想法:https://github.com/ServiceStack/ServiceStack/wiki/New-API ...在這些情況下,ServiceStack處理引發的HttpError罰款和我們不必將ResponseStatus屬性放在我們的實體DTO上。我們爲什麼要爲RequestResponse DTOs?或者我們應該到處使用RequestResponse? – Martaver