22

私のアプリケーションがサードパーティの SOA サーバーに送信するデータの中には、複雑な XML があります。サーバー所有者は XML スキーマ ( .xsd) を提供しますが、サーバーは意味のないメッセージで無効な XML を拒否するため、送信する前にローカルで検証する必要があります。

スタンドアロンの XML スキーマ バリデータを使用することもできますが、遅いのは主にスキーマ ファイルの解析に時間がかかるためです。そこで、すでに解析されたスキーマをキャッシュするHTTP サーバーの形式で、独自のスキーマ バリデーターを (問題がある場合は Java で) 作成しました。

問題は、検証プロセスの過程で多くのことがうまくいかないことです。予期しない例外と検証の成功以外:

  • サーバーは、指定されたスキーマ ファイルを見つけられない可能性があります
  • 指定されたファイルは有効なスキーマ ファイルではない可能性があります
  • XML はスキーマ ファイルに対して無効です

これは HTTP サーバーなので、意味のあるステータス コードをクライアントに提供したいと思います。上記のすべてのケースで、サーバーは400エラー ( Bad request ) で応答する必要がありますか? それとも、HTTP とは関係なく、本文にメッセージを入れて200に応答する必要がありますか? 他の提案はありますか？

更新: メイン アプリケーションはRubyで記述されていますが、これには優れた xml スキーマ検証ライブラリがないため、別の検証サーバーは過度に設計されていません。

4

7 に答える 7

28

ステータスコード422（「処理不可能なエンティティ」）は十分に近いように聞こえます：

「422（処理不能エンティティ）ステータスコードは、サーバーがリクエストエンティティのコンテンツタイプを理解し（したがって、415（サポートされていないメディアタイプ）ステータスコードが不適切）、リクエストエンティティの構文が正しいことを意味します（したがって、400（不良）リクエスト）ステータスコードは不適切です）が、含まれている命令を処理できませんでした。たとえば、このエラー状態は、XMLリクエスト本文に整形式（構文的に正しい）であるが意味的に誤ったXML命令が含まれている場合に発生する可能性があります。」

于 2010-04-17T07:23:23.857 に答える
17

検証プロセスのエラー状況を意味のある HTTP ステータス コードにマッピングすることは、完全に妥当な考え方です。

検証用の特定のスキーマを決定するために、URI を使用して XML ファイルを POST コンテンツとして検証サーバーに送信するとします。

そこで、エラー マッピングに関するいくつかの提案を以下に示します。

  • 200: XML コンテンツは有効です
  • 400: XML コンテンツが整形式ではなく、ヘッダーに一貫性がなく、要求が RFC 2616 構文と一致しませんでした
  • 401: キャッシュにスキーマが見つかりませんでした。サーバーは、スキーマ ファイルを取得するために、サード パーティの SOA バックエンドに対する認証に使用する資格情報を必要としています。
  • 404: スキーマ ファイルが見つかりません
  • 409: 指定されたスキーマに対して XML コンテンツが無効でした
  • 412: 指定されたファイルは有効な XML スキーマではありませんでした
  • 500: 検証サーバーでの予期しない例外 (NullPointerExceptions など)
  • 502: スキーマがキャッシュに見つからず、サード パーティの SOA サーバーからスキーマを要求しようとして失敗しました。
  • 503: 検証サーバーが再起動中です
  • 504: reason=timeout の場合は 502 を参照してください
于 2008-12-15T14:13:00.980 に答える
6

XML ファイルをリソースに投稿するとします。たとえば、次のようになります。

POST /validator コンテンツタイプ: application/xml

リクエスト エンティティが送信されたメディア タイプとして (つまり、アプリケーション/xml として) 解析に失敗した場合、400 Bad Request が適切なステータスです。

送信されたメディア タイプとして構文的に解析されるが、必要なスキーマに対して検証されない場合、または送信先のリソースによって処理できないセマンティクスがある場合は、422 Unprocessable Entity が最適なステータスです (ただし、おそらく、エラー応答でより具体的なエラー情報が付随するはずです; また、技術的には HTTP の拡張である WebDAV で定義されていることにも注意してください。送信されたエンティティのセマンティック エラー)。

xml の上に特定のスキーマを暗示するメディア タイプ (例: application/xhtml+xml) として送信されている場合、そのスキーマに対する検証に失敗すると、400 Bad Request を使用できます。しかし、そのメディア タイプがプレーンな XML である場合、スキーマはメディア タイプの一部ではないと主張したいと思います。xml ファイルがそのスキーマを指定している場合、検証を application/xml の構文要件の一部として解釈できます。

multipart/form または application/x-www-form-urlencoded フォーム送信を介して XML ファイルを送信する場合、XML ファイルに関するすべての問題に対して 422 Unprocessable Entity を使用する必要があります。400 は、基本的なフォームのアップロードに構文上の問題がある場合にのみ適切です。

于 2010-05-28T11:26:26.357 に答える
5

Amazon は、http ステータス コードを実際のアプリケーション レベルの条件にマッピングする方法のモデルとして使用できます: http://docs.amazonwebservices.com/AWSImportExport/latest/API/index.html?Errors.html (Amazon S3 ステータス コードの見出しを参照)

于 2009-11-03T21:03:59.827 に答える
3

w3c から: 400 = 構文が正しくないため、サーバーは要求を理解できませんでした。

実際にサーバーがリクエストを理解できない場合を除き、私はそれを提供しません。無効な xml を取得している場合は、200 を提供し、機能しない理由を説明してください。

フェイクよろしく

于 2008-12-12T12:52:06.203 に答える
2

私は400 Bad request本文にもっと具体的なメッセージを入れます（おそらく、X-Parse-Error: 10451処理を簡単にするために、ヘッダーに2次エラーコードを含めます）

于 2008-12-12T12:36:15.640 に答える
-1

これは素晴らしいアイデアのように思えますが、HTTP ステータス コードは実際には「操作が失敗した」場合を提供しません。X-Validation-Result: true/false必要に応じてテキストまたは「理由」の本文を使用して、ヘッダー付きの HTTP 200 を返します。アプリケーションレベルのエラーではなく、HTTP レベルのエラー用に HTTP 4xx を保存します。

しかし、それは一種の恥であり、ダブルスタンダードです. 多くのアプリケーションは HTTP 認証を使用しており、アプリケーション レベルから HTTP 401 Not Authorized または 403 Forbidden を返すことができます。ある種のブランケット HTTP 4xx Request Rejected を使用できると便利で賢明です。

于 2008-12-12T13:32:12.393 に答える