SOAP faultsまたはresults object？
私はこれについて同僚と話し合っていて、合意に達することができなかったので、あなたの考えを聞きたかったのです。私はこれについて自分の意見を持っていますが、私はあなたのためにそれを台無しにしません。
SOAP faultを返す必要があるのはいつですか？また、エラー情報があるresultオブジェクトを返す必要があるのはいつですか？これは、さまざまなシステム（.NET、Javaなど）で使用できる汎用Webサービス用であると想定しています。結果オブジェクトには、isErrorフラグ、errorType（特定の例外タイプに類似）、およびメッセージが含まれます。
考慮すべき点：
- データ検証エラーはエラーですか？
- 障害（非常に例外的な場合）と結果オブジェクト（「予期される」エラー）の組み合わせがあるべきですか？
- SOAPフォールト（クリティカル[null参照] vs検証[Zipコードが正しくありません]）をどのようにグループ化しますか？
- フェイルファーストとエラーチェックを忘れずに
- ベストプラクティス、パターン、標準など。
記事へのリンクは有効です。私はあなたの意見が欲しいように聞こえますが、事実に固執してください（xはyとzのために優れています...）
ほとんどのSOAPクライアントは、フォールトをランタイム例外に変換します（クライアント言語がサポートしている場合）。それを念頭に置いて、「いつスローしたいのか」という質問に言い換えることができると思います。エラー値を返すのではなく例外」？API設計全般、特にそのトピックに関する多くの意見を見つけることができると確信しています。
ただし、エラーを返すことは通常、クライアントには役立ちません。
クライアントは、スタブコードが適切なタイプの例外を生成してスローできるようにするのに対して、手動でエラーコードを列挙して処理する必要があります。エラーコードを使用すると、クライアントがスーパークラスによる例外処理などのオブジェクト指向技術を使用できなくなります。
エラーコードをWSDLの一部にしない場合;クライアントには、それらが何であるか、またはいつ発生するかについてのドキュメントはありません。型付きフォールトはWSDLの一部であるため、（ある程度は）自己文書化されます。
障害メッセージには、クライアントがエラーの報告と回復に利用できる障害固有のコンテキストを含めることができます。たとえば、実際の無効な入力要素と理由を含む入力検証フォールトをスローします。エラーコードと不透明な文字列を含む結果を返す場合、クライアントはユーザーにエラーメッセージを渡す以外に選択肢がほとんどないため、国際化やUIの一貫性などが損なわれます。
特定の質問に答えるには：
検証エラーはエラーです。エラー処理機能が制限されているAJAXクライアントからWebサービスを呼び出す場合、サービスが予期しない応答を伴う400成功コードではなく5xx HTTPコードを返すようにしたい場合を想像してください。
いいえ。APIは一貫したエラーレポートインターフェイスを提供する必要があります。 WSDLデザインはAPIデザインです。クライアントに2つの異なるエラーハンドラを強制的に実装しても、クライアントの生活は楽になりません。
障害設計では、要求/応答モデルをミラー化し、サービスの抽象化に適切な情報を表示する必要があります。 NullReferenceフォールトを設計しないでください。 XYZServiceRuntimeFaultを設計します。クライアントが無効なリクエストを頻繁に提供する場合は、適切なサブクラスを使用してInvalidRequestFaultを設計し、クライアントが無効なデータの場所をすばやく見つけられるようにします。
結果オブジェクトには結果のみを含める必要があります。結果オブジェクトが別のシステムで発生したエラーのリストを提供している場合、それは「isError」フラグを使用できる場合の例です。そうでない場合、結果が有効であるか無効であるため、できません。
エラーが発生した場合、常にSOAPFaultを使用する必要があります。検証はエラーです。検証は、データベースを開けないほど深刻ではないと考えるのは悪魔自身のtrapです。どちらの場合も同じ影響があります-要求どおりに操作を完了できません。
したがって、結果には結果オブジェクトを使用し、有効な結果オブジェクトを妨げるものにはSOAPFaultsを使用する必要があります。エラー、検証エラー、警告、バス障害などが含まれますが、これらに限定されません。
例外が発生する前は選択の余地がなかったため、多くのAPIの一貫性が失われ、ほとんどのAPIはエラーを返す方法が異なりました。各APIエントリがエラーを返す方法や、多くの場合、エラーのデコード方法やエラーの詳細を調べる方法を調べる必要があるため、恐ろしく、混乱を招き、開発の速度を低下させます。
SOAPFaults/Exceptionsを使用して検証を処理することは、考えるとより論理的であり、一度考えると、通常は簡単になります。必ずしも元の要求を必要としない方法で問題の要素を識別するのに十分な情報が含まれるように、検証障害クラスを設計する必要があります。この方法で、より一般的に検証エラーの処理を開始できます。
結果オブジェクトにエラーが含まれる場合、結果のドメイン内にのみ存在できます。たとえば、在庫切れの製品は、倉庫内の誰かがカウントできないため、在庫管理のドメイン内にあるためです。
重大なエラーと検証エラーを区別するのは賢明ではありません。重大度レベルの割り当ては非常に主観的であるため、これは有効な比較ではありません。たとえば、化学物質に関する情報を消防士に提供するシステムでは、クリティカルとはおそらく、火災のトラックが警告グラフィックをロードしようとしたときにヌル参照ではなくUN 1298およびUN 1436を運んでいることを意味します。
障害を簡潔に特定し、それに応じて処理できるように障害を設計します。それらが十分な情報を伝えていることを確認してください。 Abritraryの分類は、十分な情報が得られたときに不必要なものです。これは、フォールトによってそれ自体を特定できるためです。
SOAPFaultsが例外になったことが、フェイルファーストを実現する最も確実な方法です。
ベストプラクティス、リファレンスなど.
クライアントが結果として返されたエラーを処理する準備ができていることがわかっていない限り、簡単な答えは石鹸違反を使用することだと思います。他の回答で述べたように、例外とエラー結果の類似性も考えていました。
クライアントのニーズに応じて、例外としてもエラーとしても合理的に扱うことができる灰色の領域があります。次に、これらのタイプのエラーが返される方法を変更するパラメーターをサービスに提供できます。デフォルトではSOAPフォールトを使用しますが、クライアントがエラー結果を取得するようにパラメーターを設定した場合、結果の一部としてこれを処理する意思があることを示しています。検証エラーはこの灰色の領域にあります。ほとんどのクライアントではエラーと見なされますが、クライアントがデータを使用して検証エラーでUIをマークアップする場合は、結果の一部として検証エラーを返す方が便利な場合があります。
サービス設計で従うルールは次のとおりです。
- ビジネスレベル応答オブジェクトへの応答（ビジネス例外も含む）
- 技術/統合レベル Soap Faultへの障害
サービス利用者は、あらゆる種類のビジネスレスポンスがレスポンスオブジェクトに含まれていることを信頼し、それをサービス（ビジネス）ユーザーに提示できます。 Soap Faultsは、ビジネスレスポンスを配信できない場合にのみ使用されます。
Soap Faultsは、監視を介してサポート警告/アクションをトリガーする必要があります。