0

Drupal CMS (http://drupal.org/) 用の RESTful API の設計を支援しています。その一環として、特定のデータ オブジェクト (リソース) で複数の形式 (MIME タイプ) をサポートしたいと考えています。すべて順調です。

ただし、エラー処理のベスト プラクティスが何であるかはわかりません。具体的には、403、404、または 500 エラーの場合、どの形式でエラー メッセージを返す必要がありますか? また、それはどの程度重要ですか?

もちろん、私の最初の考えは、「要求された形式で」です。ただし、これは、適切なエンベロープを確保するために、フォーマットごとに多くの作業が必要になることを意味します。例えば：

アプリケーション/json:

{ 'error': "フラミスタンが壊れており、そのオブジェクトが見つかりません。" }

アプリケーション/json-ld+json

{ '@context': {something here}, '@error': "フラミスタンが壊れて、そのオブジェクトが見つかりません。" }

アプリケーション/xml

<error>
    <message>The framistan broke and we cannot find that object.</message>
</error>

application/atom+xml [application/xml と同じですが、20 行の Atom ラッパー マークアップがあります]

アプリケーション/svg+xml

<svg>
    <text>The framistan broke and we cannot find that object.</text>
</svg>

等々。もちろん、API の利用者は、エラー メッセージのペイロードがどのようにフォーマットされているかを知る必要があります。これは、システムに新しいフォーマットを追加したり、API と統合したりするための非常に高い障壁です。

別の言い方をすれば、ありふれたフォーマット (つまり、HTML ではない) のエラーは、常にフォーマットされていないテキスト/プレーン文字列を返すと言うことができます。そのため、HTML 以外のフォーマットを要求しているときにシステムが停止した場合は、常に、本文が「フラミスタンが壊れたため、そのオブジェクトが見つかりません。」というテキスト/プレーン メッセージが返されます。

これは、開発がはるかに簡単で、クライアントがサポートするのもはるかに簡単ですが、application/atom+xml を要求するクライアントが text/plain で応答を返す可能性があることを意味します。どうしたの？

他の誰かがこの質問に出くわしましたか? どのように解決しましたか？この状況に対処するための事実上のベスト プラクティスはありますか? 私たちが従うことができる何をすべきかを指示する仕様はどこかにありますか? 基本的に、特に REST API の領域では、「独自のことを行う」ことはできるだけ避けたいと考えています。

4

0 に答える 0