![](https://cdn-ak-scissors.b.st-hatena.com/image/square/c15088a2fe596534a690bbd7c816b7f4064092d5/height=288;version=1;width=512/https%3A%2F%2Fdata.uxmilk.jp%2Fwp-content%2Fuploads%2F2016%2F11%2Feyecatches2_error.jpg)
エントリーの編集
![loading...](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/common/loading@2x.gif)
エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。
記事へのコメント2件
- 注目コメント
- 新着コメント
注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています
![アプリのスクリーンショット](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/entry/app-screenshot.png)
- バナー広告なし
- ミュート機能あり
- ダークモード搭載
関連記事
サーバサイドエンジニアが考える、エラー発生時のより良いUX
誰のためのエラーメッセージなのか意識する 私はサーバサイドエンジニアとして API を提供する立場なの... 誰のためのエラーメッセージなのか意識する 私はサーバサイドエンジニアとして API を提供する立場なので、サーバ起因のエラーが起きたときに適切な情報を伝えるために何ができるかを考えてみます。 サーバサイドの視点では、クライアント(顧客)は2者存在すると考えることができます。 ひとつは、もちろんアプリケーションを実際に利用するエンドユーザ。 もうひとつは、サーバサイドが提供する API を利用するクライアントサイドエンジニア。 同じ事象でも対象によって伝えるべきエラーメッセージは変わってきます。 たとえば、エンドユーザにデータベースのエラーコードをそのまま伝えても不親切です。逆にクライアントサイドエンジニアに「不正なリクエストです」としか伝えなかった場合、何がどう不正なのか分からず、原因を切り分けるためにより詳しい情報を知りたいと思うでしょう。 つまり、それぞれの立場にたって「何の情報を伝え
2016/11/21 リンク