HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様
今日では HTTP(s) で API が公開されることは当たり前の時代ですが、エラーをアプリケーションにどう伝えるかは、個々の API の設計に依存していました。特に、HTTP ステータスコードは有限であり、元々持っている意味があるので、自由に使うことはできません。API はそのドメインごとにもっと複雑で細かなエラー情報があるはずで、それらはレスポンスボディに載せてアプリケーションに伝えることになりますが、その書式に規定は今までありませんでした。 HTTP API にて、アプリケーションにエラー情報を伝達するための（レスポンスボディに載せられる）標準的な形式が、RFC7807 Problem Details for HTTP APIs で定められています。適用例としては、以下のようになります。 HTTP/1.1 403 Forbidden Content-Type: application
WebAPIでエラーをどう表現すべき？15のサービスを調査してみた - Qiita
2017-01-05 追記 2016年3月にエラーの標準形式RFC7807「Problem Details for HTTP APIs」が提案され、今日現在proposed standard(標準化への提唱)となっています。こちらも是非ご覧ください。 RFC 7807 - Problem Details for HTTP APIs HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様 最近はREST APIを提供しているサービスが増えてきていますね！また公開されるAPIだけでなく、Microservicesなアーキテクチャを採用して、バックエンドがWeb APIで通信するケースも増えてきているように思います。 APIを使うときはあまり気にしたこともなかったですが、いざAPIを設計してみるとどんなインターフェイスがいいのか、どんな形式がいいのかといった疑問が次々と出てきます。
RESTful APIのエラー設計 - Qiita
RESTful APIのレスポンスデータ設計の最後でも述べたが、APIでエラーが発生した時のレスポンスデータも検討する必要がある。 エラー発生時のレスポンスデータの考え方 APIのレスポンスデータはほとんどの場合プログラムで処理されるため、エラーが発生した時も、 どんなエラーが発生したのか そのエラーはなぜ発生したのか そのエラーはどうすれば解決できるのか をプログラムが分かるようにしておく仕組みが必要。 エラー発生時のレスポンスデータ 1. HTTPステータスコードの設定 エラーが発生したら、レスポンスボディにエラー情報を設定するだけでなく、(RESTful APIのHTTPステータスコード設計でも書いた通り)適切なHTTPステータスコードを設定する必要がある(エラーが発生しているのに200を設定したりしないこと、200はリクエストが成功した時のみしか返してはいけない)。 2. レスポン
「結論から意見を言うと怒られる会社」にいたことがあった。
ところで私は、昔 「相手に対する賛成意見や良い報告は結論から言うのがいい。けど、反対意見や悪い報告は理由から言いなさい」 と真面目に指導されたことがあります。 先日、安達さんのこんな記事を拝読しました。 「コンサル一年目が学ぶこと」を読んで、コンサル会社の「容赦ない」カルチャーについて思い出した。 で、別に反対とかアンチテーゼというわけではないんですが、特に下記の部分で、色々と昔のことを思い出したんです。 なお「結論から言う」カルチャーは、仕事にたいへん役に立つが、結構な訓練が必要だ。 いや、できる人は何の意識もせずにできてしまうのだが、できない人は何をどう説明しても、なかなかできない。 「ノウハウ」を聞いただけではダメなのだ。 だが、それを毎日、報告のたびにしつこくしつこく言われることで、二年目に入る頃にはそこそこ皆ができるようになる。 「結論から言う」カルチャーの話ですね。 今なら、結
Web API 設計のベスト プラクティス - Azure Architecture Center
ほとんどの最新の Web アプリケーションでは、クライアントがアプリケーションと対話する際に使用できる API を公開しています。 適切に設計された Web API には、次をサポートする目的があります。 プラットフォームの独立。 API の内部的な実装方法に関係なく、すべてのクライアントが API を呼び出すことができる必要があります。 そのためには、標準プロトコルを使用し、クライアントと Web サービスが交換するデータの形式に同意できるメカニズムを備えている必要があります。 サービスの進化。 Web API はクライアント アプリケーションから独立して進化し、機能を追加できる必要があります。 API の進化に伴い、既存のクライアント アプリケーションが変更なしに引き続き機能する必要があります。 クライアント アプリケーションが機能を十分に使用できるように、すべての機能が検出可能である
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
