入念に考慮されていると思います。提供する立場から考えてみました。氏とあるアプリのサーバサイドのエンジニア。技術の未来予測やデザインのリノベーションなどが趣味。エラーメッセージとはエラーメッセージとは、予期せぬ状態が発生したときに表示されるメッセージのことです。このようなダイアログに見覚えがある人は多いと思います。統合して表示するほうが適切な場合もあります。提供する立場なので、サーバ起因のエラーが起きたときに適切な情報を伝えるために何ができるかを考えてみます。サーバサイドの視点では、クライアント(顧客)は2者存在すると考えることができます。ひとつは、もちろんアプリケーションを実際に利用するエンドユーザ。利用するクライアントサイドエンジニア。同じ事象でも対象によって伝えるべきエラーメッセージは変わってきます。エンドユーザにデータベースのエラーコードをそのまま伝えても不親切です。逆にクライアントサイドエンジニアに「不正なリクエストです」としか伝えなかった場合、何がどう不正なのか分からず、原因を切り分けるためにより詳しい情報を知りたいと思うでしょう。それぞれの立場にたって「何の情報を伝えるのが親切なのか?」と再考することが大事になってきます。ヒューマンインタフェースガイドラインでは、一般的なエラーの表示方法には2種類あると書かれています。出典:マテリアルデザインガイドラインアラートダイアログが表示されているときは、他のコンポーネントが操作不能になるため、致命的なエラーを通知するときに使用するのがベターとされています。アラートダイアログに表示すべき文言のガイドラインも存在します。ヒューマンインタフェースガイドラインからの部分抜粋です。状況を簡潔に記述し、その状況でユーザが実行できることを説明する。理想的には、用意したテキストは、アラートが表示された理由を理解し、どのボタンをタップするべきか決定するために必要十分なコンテキストをユーザに与えます。一般に、2つのボタンのアラートを設定する。ユーザは2つの選択肢から選ぶのがもっとも簡単であるため、多くの場合、2つのボタンのアラートがもっとも有用です。1つのボタンのアラートは、ほとんどの場合役に立ちません。その状況に対処するための手段を与えるものではないからです。3つ以上のボタンを含むアラートは2つのボタンのアラートよりかなり複雑なので、できるだけ避けるべきでしょう。ボタンが多すぎるとスクロールが必要になり、使い勝手が悪くなってしまいます。サーバサイドで定義したエラーメッセージをエンドユーザにそのまま表示する場合は、こういったことを意識するとともに、アプリケーション全体のトーン&マナーを揃えることも大事です。アプリケーション全体の体験を統一するには、エラーメッセージのリソースファイルをデザイナーが編集できると良いと思います。コールしたら下記のようなレスポンスが返ってきたとします。"error_message":"不正なリクエストです"}リクエストパラメータがひとつだけだった場合ならまだしも、これだけでは対処方法が不明瞭で、どのリクエストがどのように不正なのかが分かりません。細かいエラーハンドリングをクライアントサイドで行う場合もあるので、エラーコードはある程度細かい粒度で定義するほうが良いでしょう。レスポンス(JSON形式)を挙げてみます。オブジェクトはエンドユーザ向けの情報を返すようにしています。errorsオブジェクトは、どの項目がどのようなバリデーションに引っかかったのかをそれぞれ返します。このような形式であれば、開発者とエンドユーザーの両者にとって有益な情報となるのではないでしょうか。"バリデーションエラーが発生しました。"入力した形式に間違いがあります。"お手数ですがもう一度入力してください。["メールアドレスは必須です。["8文字以上のパスワードを入力してください。","パスワードに使用できない文字が含まれています。"バリデーションエラーが発生しました。"入力した形式に間違いがあります。"お手数ですがもう一度入力してください。"メールアドレスは必須です。"8文字以上のパスワードを入力してください。"パスワードに使用できない文字が含まれています。まとめ正常系でない部分の実装は、どうしても優先度も低くなり後回しにしがちです。異常な事が起こったときに親切なメッセージを出してあげられるかどうかは、ユーザのストレスをいかに軽減するかという部分に直結し、サポート対応のコストにも大きく響く部分です。誰にとっても分かりやすいエラーメッセージを心がけたいですね。嶺1987.1.24生まれ。とあるアプリのサーバサイドのエンジニア。技術の未来予測やデザインのリノベーションなどが趣味。最近は、おいしいカプチーノに巡りあうために、都内のカフェを巡っています。