62

これについて同僚と話し合っていたのですが、合意に達することができなかったので、あなたの考えを聞きたかったのです。私はこれについて私自身の意見を持っていますが、あなたのためにそれを台無しにするつもりはありません.

いつSOAP エラーを返す必要がありますか? また、エラー情報を含む結果オブジェクトを返す必要があるのはいつですか? これは、さまざまなシステム (.NET、Java など) で使用できる一般的な Web サービス用であると想定します。結果オブジェクトには、isError フラグ、errorType (特定の例外タイプに類似)、およびメッセージが含まれます。

考慮すべき点:

  1. データ検証エラーは障害ですか?
  2. フォールト (非常に例外的なケース) と結果オブジェクト (「予想される」エラー) の組み合わせが必要ですか?
  3. SOAP エラーをどのようにグループ化しますか (クリティカル [ヌル参照] と検証 [郵便番号が正しくありません])?
  4. フェイルファスト vs エラーチェックを忘れずに
  5. ベスト プラクティス、パターン、標準など

記事へのリンクは有効です。あなたの意見が欲しいように聞こえますが、事実に固執してください(x は y と z により優れています...)

4

4 に答える 4

60

ほとんどの SOAP クライアントは、障害を実行時例外に変換します (それがクライアント言語でサポートされている場合)。それを念頭に置いて、「いつエラー値を返す代わりに例外をスローしたいのか」という質問を言い換えることができると思いますか? その API 設計全般、特にそのトピックについて、多くの意見を見つけることができると確信しています。

とはいえ、通常、エラーを返すことはクライアントにとって役に立ちません。

  1. クライアントは、エラー コードを手動で列挙して処理する必要があります。スタブ コードが適切なタイプの例外を生成してスローできるようにする必要があります。エラー コードを使用すると、クライアントは、スーパークラスによる例外処理などのオブジェクト指向の手法を使用できなくなります。

  2. エラー コードを WSDL の一部にしない場合。クライアントには、それらが何であるか、またはいつ発生するかについてのドキュメントがありません。型指定されたフォルトは WSDL の一部であるため、(ある程度限定された範囲で) 自己文書化されます。

  3. 障害メッセージには、クライアントがエラーの報告と回復に利用できる障害固有のコンテキストを含めることができます。たとえば、実際の無効な入力要素と理由を含む入力検証エラーをスローします。エラーコードと不透明な文字列を含む結果を返す場合、クライアントはエラーメッセージをユーザーに渡すしかありません。これにより、国際化、UI の一貫性などが損なわれます。

特定の質問に答えるには:

  1. 検証エラーは障害です。エラー処理機能が制限された AJAX クライアントから Web サービスを呼び出したとします。予期しない応答を伴う 400 成功コードではなく、サービスが 5xx HTTP コードを返すようにしたい場合。

  2. いいえ。API は、一貫したエラー報告インターフェイスを提供する必要があります。WSDL 設計は API 設計です。クライアントに 2 つの異なるエラー ハンドラーを実装するように強制しても、クライアントの作業が楽になるわけではありません。

  3. 障害設計は、要求/応答モデルを反映し、サービスの抽象化に適した情報を表示する必要があります。NullReference フォールトを設計しないでください。XYZServiceRuntimeFault を設計します。クライアントが無効なリクエストを頻繁に提供する場合は、適切なサブクラスを使用して InvalidRequestFault を設計し、クライアントが無効なデータの場所をすばやく特定できるようにします。

于 2010-06-21T18:17:11.020 に答える
45

結果オブジェクトには、結果のみを含める必要があります。結果オブジェクトが別のシステムで発生したエラーのリストを提供している場合、これは「isError」フラグを持つことができる場合の例です。それ以外の場合は、結果が有効かどうかのいずれかであるため、できません。

エラーが発生した場合は、常に SOAPFault を使用する必要があります。検証はエラーであり、データベースを開くことができないことよりも検証をそれほど深刻ではないと考えるのは、悪魔自身の罠です。どちらの場合も同じ影響があります。要求どおりに操作を完了できません。

したがって、結果には結果オブジェクトを使用し、有効な結果オブジェクトを妨げるものには SOAP フォールトを使用する必要があります。エラー、検証の失敗、警告、バス障害などを含みますが、これらに限定されません.

例外が発生する前は選択肢がなく、その結果、多くの API に一貫性がなくなり、ほとんどの API でエラーを返す方法が異なっていました。各 API エントリがどのようにエラーを返すか、また多くの場合、どのようにデコードするか、またはエラーの詳細を調べる必要があるため、これは恐ろしく、紛らわしく、しばしば開発を遅らせます。

  1. SOAPFaults / Exceptions を使用して検証を処理することは、考えてみるとより論理的であり、一度考えてみると通常は簡単です。元の要求を必ずしも必要としない方法で問題のある要素を特定するのに十分な情報が含まれるように、検証エラー クラスを設計する必要があります。このようにして、検証エラーをより一般的に処理し始めることができます。

  2. 結果オブジェクトにエラーが含まれている場合、それらは結果のドメイン内にのみ存在できます。たとえば、倉庫の誰かが数えられないために在庫切れになっている製品は、在庫管理のドメイン内にあります。

  3. 重大なエラーと検証エラーを区別するのは賢明ではありません。重大度レベルの割り当ては非常に主観的であるため、これは有効な比較ではないと思います。たとえば、消防士に化学物質に関する情報を提供するシステムでは、クリティカルとはおそらく、火災のトラックが UN 1298 および UN 1436 を運んでおり、警告グラフィックを読み込もうとしたときにヌル参照ではないことを意味します。

    障害を簡潔に識別し、それに応じて処理できるように障害を設計します。それらが十分な情報を伝えていることを確認してください。フォールト自体を特定できるため、十分な情報が得られている場合は、不要な分類は不要です。

  4. SOAPFaults を Exceptions に変換することは、フェイルファーストを実現する最も確実な方法です。

  5. ベスト プラクティス、リファレンスなど

于 2010-06-22T14:30:01.423 に答える
8

クライアントが結果として返されるエラーを処理する準備ができていることがわかっていない限り、短い答えはソープフォールトを使用することだと思います。他の回答で述べたように、例外とエラー結果の類推も考えていました。

クライアントのニーズに応じて、例外として合理的に処理され、結果としてエラーとして処理される灰色の領域があります。次に、これらのタイプのエラーが返される方法を変更するパラメーターをサービスに提供する場合があります。デフォルトでは SOAP エラーが使用されますが、クライアントがパラメーターを設定してエラー結果を取得する場合は、これを結果の一部として処理する意思があることを示しています。私にとって、検証エラーはこの灰色の領域にあります。ほとんどのクライアントにとって、これは障害と見なされますが、クライアントがデータを使用して UI に検証エラーをマークアップしたい場合は、検証エラーを結果の一部として返す方が便利な場合があります。 

于 2010-06-25T17:40:37.763 に答える