2009-08-24 17 views
3

私はRestWebserviceを作成/検索のような基本的な操作のために使用しています。要求XMLが正常に動作させるために、このRest WebServiceエラー処理

<customer> 
    <name/> 
    ..... 
</customer> 

ようになり、私はそれに移入余分なフィールドを持つ同じ顧客のXMLを返します(リクエストに空白僕ら例えばシステムIDなど)。 with Response.Status = 2000

正常に動作しない場合は、このようなエラーコードを返します。 例えばのResponse.Status = 422(処理不能エンティティ) のResponse.Status = 500(内部サーバーエラー)と、数など..

<errors> 
<error> An exception occurred while creating the customer</error> 
<error> blah argument is not valid.</error> 
</errors> 

今、私はこのエラーを送信する正しい方法であるかどうか、わかりませんクライアントに送信します。たぶんそれは応答のヘッダーに存在するはずです。

本当にありがとうございます。 ありがとう!

+1

この質問を参照してくださいhttp://stackoverflow.com/questions/942951/rest-api-error-return-good-practicesこれはほぼ同じ問題です。 –

答えて

2

"Request"または "Response"ラッパーでXMLをラップします。

例えば、より重要なの

<customerrequest> 
    <customer> 
    .. 
    </customer> 
</customerrequest> 

とは:

<customerresponse> 
    <status>success | failure</status> 
    <customer> <!-- If success --> 
    ... 
    </customer> 
    <errors> <!-- If failure --> 
    <!-- never underestimate the value of having a machine-friendly error code 
      for each possible error, or critical/non-critical errors --> 
    <error code="0001">An error occurred</error> 
    </errors> 
</customerresponse> 

また、これはあなたのサービスが成熟するにつれて、要求/応答タグ内で必要として、あなたは余分な非データフィールドを追加できることを意味します。または参照番号。認証の詳細。

SOAPを使用していた場合、私は個人的にかなり制限されていますが(それほど深く調査したわけではありませんが)、SOAPに組み込まれている既存のエラー処理を使用できます。

+0

@ JeeBee:不正なXMLを取得した場合。私も解析することはできませんが、私はそれらにエラータグを返信することはできません。 その場合、私は最終的にplain errors.xmlを作成する必要があります –

+0

ああ、XMLをRESTサービスのStringとして操作しているだけですか?どうして? – JeeBee

+0

私はXMLというだけの文字列ではありません。文字列/ xmlをDTOオブジェクトに変換するために、xStream(XMLを直列化/直列化解除するライブラリ)を使用しています。それを私のドメインオブジェクトにマッピングし、必要な操作を行います。 –

8

エラーの正しいRESTアプローチは、HTTPステータスコードを使用することです(実行中のように聞こえます)。彼らの驚異的な配列(as you can see here)があり、あなたがどれほど多くの一般的な状況に合っているかを見ると驚くかもしれません。

フレンドリーなエラーメッセージには2つの選択肢があります。まず、HTTP応答(see the Wikipedia article on HTTP for more info)のステータスコードの後に​​、ステータスコードのテキスト説明を入力できます。このテキストは、HTTP仕様ではなくサーバーによって決定され、送信する特定のメッセージに柔軟性を与えます。ほとんどのサーバー側のフレームワークは、このテキストをプログラマチックに設定する方法を提供します。しかしながら!ステータスコードの記述を乱用しないようにすることがベストプラクティスです。なぜなら、ユーザーのWebクライアントがそれを読み取るかどうかを保証することはできないからです(ステータスコードだけを読み、標準のHTTP記述を使用することが好ましい)。私はあなたのステータスの説明がシンプルで、サーバとクライアントを制御しているので(あなたが何を得ているのかを知るために)、このアプローチを使うことをお勧めします。私の経験では、このアプローチは5xxのコード範囲ではうまく機能しますが、他の多くのコードでは使用しません。

2つ目のオプションは、エラーステータスコードとエラーの説明をメッセージの本文として返すことです。それがベストプラクティスです。それがあなたのために働いている場合、変更する必要はありません。これは、エラーメッセージ自体(HTTPレスポンスのステータスコードの後に​​続くテキスト)ではなく、「追加情報をエラーと考える」と考えるのが役に立ちます。