設計一個簡單的Web服務與返回代碼的最佳實踐

我正在設計一個WCF服務，將返回一個響應代碼（如0爲成功，或另一個數字的錯誤）。此外，Web服務的所有方法都將執行幾個常見的驗證（例如驗證apiKey）。設計一個簡單的Web服務與返回代碼的最佳實踐

我想知道是否有最佳實踐方法或組織和檢索這些響應代碼和消息。

感謝您的任何建議。

2010-09-10 dotariel

理想情況下，不要使用響應代碼。成功返回可用的東西（或無效）並在失敗時拋出異常。

人們處理異常。我們經常忘記查看返回的代碼，特別是當99％的時間成功時，我們不關心任何響應。所以我們不捕捉。然後我們不費心檢查失敗。然後，我們花了2天的時間跟蹤一個我們無法找到的錯誤，因爲沒有拋出異常，我們不知道600,000行應用程序在哪裏使用您的web服務失敗...我們甚至不知道這是一個打電話給您失敗的web服務。只是由於某些未知原因，某些數據是錯誤的。

有一個話題在SO一下：Which and Why do you prefer Exceptions or Return Codes

來源

2010-09-10 16:15:01 CaffGeek

乍得，這很有道理。但是，可以從Web服務拋出異常，而不知道服務是從哪個平臺消耗的？我最初的想法是建立一個封裝代碼和消息的DataContract。這將如何被替換爲一個異常？ – dotariel 2010-09-10 21:31:35

@ XSaint32，不能說我做了很多，但我不認爲這是一個問題。我很確定我有一個調用Java服務的.NET應用程序，它捕獲了沒有問題的異常。結果最終將被序列化爲xml/soap。據我所知，當你添加一個web服務引用時生成的類會處理這個事件。 – CaffGeek 2010-09-10 21:55:19

這種方法將與xml/soap包裝器一起工作，但我可能需要使用REST提供這些服務。一個RESTful服務能夠拋出HTTP豁免以外的任何東西嗎？我需要假定使用Web服務的客戶端可能是一個簡單的PHP cURL站點。 – dotariel 2010-09-11 00:45:44

不要直接使用返回代碼。返回碼通常意味着成功，預期失敗和意外失敗。 Web服務將此機制替換爲期望的故障和意外故障。請檢查FaultContract和FaultException<T>以獲取預期故障的實施細節。意外的錯誤是其他任何異常。這是最佳做法。

來源

2010-09-10 19:24:37

設計一個簡單的Web服務與返回代碼的最佳實踐

回答

相關問題