RESTful APIと対話するアプリケーションを設計しています。
Unable to sign up user
のようなエラーメッセージを返す場合
エラーメッセージはアプリによって生成されますか?またはAPIによって?ベストプラクティスを探しています。
少なくとも、REST apiは、アプリケーションが表示するために取得できるエラーコード(例:123)および/またはエラーキー(例: "cannotRegister")を返す必要があります関連メッセージ。これは、複数の言語で利用可能なアプリケーションを処理する場合にも役立ちます。アプリは、適切なリソースバンドル(翻訳)から関連メッセージを選択できます。APIは、どの言語であるかを知る必要はありません。ユーザーはアプリケーションを表示しています。
APIで可能な限り多くのエラーを処理しようとしています。複数のクライアントが存在する環境では、これにより、物事の一貫性を保ち、維持しやすくなります。
APIを介してエラー処理を実行する場合、単なるステータスコードでは十分ではありません。私がここで取っているアプローチは、人間が読めるメッセージと開発者向けのより詳細なメッセージを提供する追加のエラーレスポンス本文と、追加の説明を提供するその他のリソースへのリンクを提供することです。 JSONでは、これは次のようになります。
{
"status": 404,
"code": 404-07,
"message": "Ooops! Seems like the file does not exist.",
"developerMessage": "File resource for path /uploads/foobar.txt does not exist.",
"moreInfo": "http://www.mycompany.com/errors/404-07"
}
stormpath 。からの例
次に、クライアントは人間が読めるmessage
を使用して、エンドユーザーに直接提示します。
I18nを処理するには、HTTP Accept-Language
およびContent-Language
ヘッダー。エラーメッセージは、目的の言語で配信されます。
APIは、アプリケーションに必要な情報を提供するためにできることは何でもすべきです。しかし、ユーザーにとって、メッセージは最も可能性が高いです:
None - for things like updates, prefetch etc. or where retrying helps.
Tell them "it didn't work".
Tell them "it didn't work, it might work later".
Tell them "it didn't work, here's what you can do to fix it"
Tell them "it didn't work, give this cryptic information to the help desk".
しかし、状況とサーバーからの情報に基づいて、そこで決定するのはアプリケーション次第です。サーバーは、ユーザーに適したメッセージを知ることができません。