Webサービスをコーディングするとき、戻り値をどのように構造化しますか？エラー状態（予期しないものや予期しないもの）はどのように扱いますか？ intのような単純なものを返すのであれば、それを返すか、より複雑なオブジェクトに埋め込みますか？ 1つのサービス内のすべてのWebメソッドが単一のクラスのインスタンスを返すか、メソッドごとにカスタム戻り値クラスを作成しますか？Webメソッドの戻り値に適したデザインパターンは何ですか？
私はリクエスト/レスポンスオブジェクトパターンが好きです。ここでは、単純なパブリックプロパティを持つ1つの[Operation] Requestクラスに引数をカプセル化します。
AddCustomerRequestと同様に、AddCustomerResponseを返します。
応答には、操作の成功/失敗に関する情報、UIで使用される可能性のあるメッセージ、場合によっては追加された顧客のIDなどが含まれます。
もう1つの良いパターンは、これらがすべて一般的なエンドポイントがProcess（params IMessage [] messages）のような単純なIMessageインターフェイスから派生するようにすることです。同じ方法で複数の操作を渡すことができますウェブリクエスト。
+1ベンの答えです。
さらに、包括的な応答では、複数のエラー/警告項目が許可されているので、できるだけ包括的かつ実用的な返信ができるようにすることをお勧めします。 （最初のエラーメッセージの後に停止したコンパイラを使用するか、できるだけ多くのことを伝えたコンパイラを使用しますか？）
SOAP Webサービスを使用している場合は、SOAP faultsがエラーの詳細を返す標準的な方法です。フォルトメッセージは、あなたが好きな追加の詳細を返すことができます。
Soapフォルトは、呼び出し元のアプリケーションがSoapクライアントである標準的な方法です。 XMLHTTPを使用するCOMクライアントのように、SoapがXMLとして解析され、Soapフォルトが簡単に処理できない場合があります。まだ投票できませんが、もう1つの+1は@Ben Scheirmanです。