HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様
今日では HTTP(s) で API が公開されることは当たり前の時代ですが、エラーをアプリケーションにどう伝えるかは、個々の API の設計に依存していました。特に、HTTP ステータスコードは有限であり、元々持っている意味があるので、自由に使うことはできません。API はそのドメインごとにもっと複雑で細かなエラー情報があるはずで、それらはレスポンスボディに載せてアプリケーションに伝えることになりますが、その書式に規定は今までありませんでした。 HTTP API にて、アプリケーションにエラー情報を伝達するための（レスポンスボディに載せられる）標準的な形式が、RFC7807 Problem Details for HTTP APIs で定められています。適用例としては、以下のようになります。 HTTP/1.1 403 Forbidden Content-Type: application
HTTP Status: 204 No Content and 205 Reset Content, by Ben Ramsey
The 200 range of HTTP status codes represents successful requests. I’ve already covered 201 Created and 202 Accepted and 206 Partial Content. Today, I’ll wrap up my discussion of the 200 range by talking about 204 No Content and 205 Reset Content. The 200 OK response is probably the status with which most are familiar, and I’ll discuss it later when covering the HTTP verbs. The 204 No Content resp
nginxのステータスコード499 · yuuki/yuuki
// https://github.com/nginx/nginx/blob/9842cff/src/http/ngx_http_request.h#L120-L126 /* * HTTP does not define the code for the case when a client closed * the connection while we are processing its request so we introduce * own code to log such situation when a client has closed the connection * before we even try to send the HTTP header to it */ #define NGX_HTTP_CLIENT_CLOSED_REQUEST 499 HTTP標準で
HTTPステータスコードを適切に選ぶためのフローチャート : 難しく考えるのをやめよう | POSTD
HTTPステータスコードを返すというのはとても単純なことです。ページがレンダリングできた？よし、それなら 200 を返しましょう。ページが存在しない？それなら 404 です。他のページにユーザをリダイレクトしたい？ 302 、あるいは 301 かもしれません。 I like to imagine that HTTP status codes are like CB 10 codes. "Breaker breaker, this is White Chocolate Thunder. We've got a 200 OK here." — Aaron Patterson (@tenderlove) 2015, 10月 7 訳：HTTPのステータスコードのことは、市民ラジオの10コードみたいなものだと考えるのが好きです。「ブレーカー、ブレーカー、こちらホワイト・チョコレート・サンダー。200
Railsアプリケーションの422エラーページの文言をどうするといいのか調べてみた - Qiita
rails newでプロジェクトを作成すると、public配下に404.html, 422.html, 500.htmlというHTMLがデフォルトで生成されます。生成される文言は英語なので日本語にしようとした際に、そのままの翻訳ではユーザがこのエラーに遭遇したときにどうもわかりにくい気がするので、「404 文言」とかでGoogle先生に聞くと非常に参考になる文言をみつけることができます。 500も同様にGoogle先生でみつけられるのですが、422はなんだかどうもピンとくるのが見つけられなかったのです。 なので、そもそもこのエラーに遭遇するタイミングと他のサイトがどうしているのかどうかを調べてみました。 エラーに遭遇するタイミング そもそも、422とはWikipediaによると、 422 Unprocessable Entity 処理できないエンティティ。WebDAVの拡張ステータスコード
先輩と覚える HTTP ステータスコード
gistfile1.md 先輩に学ぶ HTTP Status Code 超雑にまとめました。修正してください。 登場人物 アプリケーション先輩: いつも忙しい。横に広がるのが得意(デブじゃない)。 後輩: 頼んでばっかしで役に立たない。 サーバー先輩: アプリケーション先輩と仲がいい。Unix Socket でつながるくらい仲良し。 プロクシ先輩: アプリケーション先輩とかサーバー先輩と後輩の間を取り持って代わりに伝えたりしてくれる。たまに勝手にレスポンスを書き換える。 1xx 系 100 Continue 後輩「あ、先輩！お願いが！」 アプリケーション先輩「おー、聞いてやる。詳しく話せ」 101 Switching Protocols 後輩「せんぱーい、お願いなんですけどー」 アプリケーション先輩「ちょっと待て、お前 HTTP 1.0 で喋るな、 HTTP 1.1 か TLS 1.0 で
HTTPで正しくキャッチボールをするには | Lab by engineering@dwango.jp
皆さんはキャッチボールは好きですか? 私はバスケットボールの方が好きです。 キャッチボールは、自分と相手双方がボールをうまくキャッチできるように投げる必要があります。これは、サーバーとクライアントの間でも同じで、クライアントから投げられたボール(リクエスト)をサーバーは正しく投げ返す(レスポンス)必要があります。 ここで、サーバーがボールをあさっての方向に投げたり、異常なスピードで投げ返すとどうなるでしょうか。おそらくクライアントはそのボールを取ろうとしますが、追いつけずにボールを落としたり、どこかにぶつけたりしてしまうでしょう。 今回は、HTTPについて、どうして正しくレスポンスを返さないといけないのかということについて、Rackを使用して解説していきます。 対象読者 Webアプリケーション開発に興味のある方、これから開発を行おうとしている方 Rackについて まず、今回使用するツール
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
April King — HTTP Status Code Handling