0

私は開発した RESTful Web サービスのセットを持っており、ユーザーのエラーを便利な方法で処理しようとしています。

アカウント リソースの URL を誤ってコーディングし、404 エラーが発生する状況に遭遇しました。サーバーには応答する @Path アノテーションがなかったため、エラーが発生することが予想されました。しかし、404 を受け取ったので、アカウント番号が見つからないことをユーザーに報告しました。

/server/foo/123450 (リソースへの正しいパスが /server/bar/123450 の場合) に「リソース」がなかったため、純粋に RESTful な観点から、404 は「理にかなっています」と思います。しかし、/server/thisPathHasNoHopeOfExisting/123450 も 404 を返します。

口座番号 00000 が存在しない /server/bar/000000 は 404 を返します。

ユーザーに正しいことを伝えるにはどうすればよいですか? (その /server/thisPathHasNoHopeOfExisting/xxxxxx は真のサーバー エラー、500 シリーズです。これは、サーバーが応答しないためです) -- 私の Jersey サービスを少し REST に詳しくする方法はありますか?

4

1 に答える 1

0

How can I tell my user the right thing?

404は正しいことです。

(that /server/thisPathHasNoHopeOfExisting/xxxxxx is a true server error

どう言う意味ですか？サーバーエラーの原因は？クライアントはそれを求めた人ですよね？「実際の」REST インターフェースを作成している場合は、アプリケーション状態のエンジンとしてハイパーメディアを使用しています。クライアントは /server/thisPathHasNoHopeOfExisting/ について考えていません。

Jersey/JAX-RS では、UriBuilder を使用して URI を作成できます。次に、「URIのコードミス」はありません。

JAX-RS の優先順位規則を使用して、ある種のキャッチオール ページを作成できるかもしれませんが、それが非常に効果的かどうかはわかりません。つまり、存在するつもりだったが存在しない可能性があるリソース (存在しないアカウントなど) と、存在するつもりのないリソースをどのように区別できるでしょうか? あなたの問題は省略のエラーに起因するため、考案できるソリューションは、そのようなエラーの可能性も継承します。UriBuilder を使用します。

于 2013-03-11T19:44:53.027 に答える