RESTful APIのHTTPステータスコード設計 - Qiita
RESTfulなAPIでは、以下の理由によりAPIの処理結果は適切なHTTPステータスコードを利用することが推奨されている。 適切なHTTPステータスコードを返さないと、レスポンスボディの中身を解析して処理結果を判定する必要がある HTTPの標準仕様を使うことで、HTTPステータスコードから処理結果を判定することができる HTTPの標準仕様を使うことで、APIを利用する第三者にとっても理解しやすくなりバグの混入を減らすことができる ほとんどのHTTPクライアントライブラリはHTTPステータスコードを見てリクエストが成功したか、失敗したかを判別している ※ステータスコードは一律200で処理結果をレスポンスボディで表現するようなことはしてはいけない。例えば、API側で内部エラーが発生し本来であれば500(INTERNAL SERVER ERROR)を返さなければいけないところを、200で返して
HTTP/3 の特徴 HTTP/2とQUICの違い | REDBOX Labo
今回は改めてHTTP/3とはどのようなもので、QUICとは何か、HTTP/2時代からの改善点と我々はHTTP/3の波に乗るべきなのかチェックしていきたいと思います。時がたち次世代Web通信プロトコル「HTTP/3」の標準化プロセスが完了し、2022年6月に「RFC 9114」となりました。既に基盤となる「QUICプロトコル」の標準化プロセスも完了し、RFC9000としてRFCとなりました。もうHTTP/3は無視出来ないところまできています。 HTTP/3の誕生と歴史HTTP/3とは、HTTP/1.1 HTTP/2に続く新しいバージョンの約束事です。HTTP/1.1からHTTP/2は様々な点で劇的な進化を遂げましたが、HTTP/3はHTTP/2の根本的な課題をTCP・TLSの融合という形で解決し問題点を補うよう進化してきました。 1991年：HTTP/0.9（HTTPの始まりGETメソッドし
こんばんは、X-Forwarded-For警察です - エムスリーテックブログ
エムスリーエンジニアリンググループ製薬企業向けプラットフォームチームの三浦 (@yuba)です。普段はサービス開発やバッチ処理開発をメインにやっておりますが、チームSREに参加してからはこれに加えて担当サービスのインフラ管理、そしてクラウド移行に携わっています。 今回はそのクラウド移行の話そのものではないのですが、それと必ず絡んでくるインフラ設定に関してです。 アクセス元IPアドレスを知りたい Webアプリケーションがアクセス元IPアドレスを知りたいシーンというのは、大まかに二つかと思います。ログ記録用と、アクセス制限ですね。どちらもアプリケーションそのものではなく手前のWebサーバの責務のようにも思えますが、そうとも言い切れません。動作ログ、特に異常リクエストをはじいた記録なんかにセットでIPアドレスを付けたいとなるとアプリケーション要件ですし、アクセス制限についてもマルチテナントサービ
HTTPステータスコード一覧と詳細ガイド
HTTPステータスコードは、ウェブページに追加されるサーバーからの短いメモのようなもの。これは実際にはサイトのコンテンツの一部ではなく、サーバーからのメッセージであり、特定のページを表示するリクエストを受信したときの状況を知らせてくれます。 このようなメッセージは、ブラウザがサーバーとやり取りするたびに（たとえあなたが目にすることがなくても）返されます。ウェブサイト所有者、開発者であれば、HTTPステータスコードの意味を理解することが重要です。HTTPステータスコードは、表示されたとき、ウェブサイトの構成エラーを診断、修正するための貴重なツールとなります。 今回の記事では、いくつかのサーバーステータスとエラーコードを扱い、それらが意味するところ（つまり、サーバーで何が起きているか）についてご説明します。 それでは、早速始めましょう！ HTTPステータスコードとは？ リンクをクリックするか、
HTTPステータスコード一覧とリクエストとレスポンスの意味を解説 | ITコラム｜アイティーエム株式会社
HTTPのwwwとは？ WWW(World Wide Web)（略してWeb）とは、ハイパーテキストと呼ばれている形式で作られた文書をサーバに格納し、ネットワーク経由で閲覧する機能を提供するサービスです。ハイパーテキストとは、テキストファイルの中にハイパーリンク（他のドキュメントへの参照情報）が埋め込まれたもので、そのハイパーリンクをたどることによって、複数の文書を関連付けたり、1つのファイルでは表現できない大きな情報を表したりすることが出来ます。WWWでは、主にHTML(HyperText Markup Language)を使って、このハイパーテキストを記述します。ハイパーテキストを実現するには、Web上に存在する文書や各種ファイルを指し示す方法が必要になります。そのために用いられるのがURL(Uniform Resource Locator)です。URLはWebブラウザでWebサーバを
HTTP/3はどうやってWebを加速するか？ TCP、TLS、HTTP/2の問題とHTTP/3での解決策～Fastly奥氏が解説（後編）
HTTP/3はどうやってWebを加速するか？ TCP、TLS、HTTP/2の問題とHTTP/3での解決策～Fastly奥氏が解説（後編） Webの世界では新しいHTTPの標準として「HTTP/3」の策定が進み、現在最終段階にあります。このHTTP/3はこれまでのHTTPをどのように改善し、高速化を実現していくのでしょうか。 2020年11月25日と26日にオンラインで開催されたFastly Japan主催のイベント「Yamagoya Traverse 2020」のセッション「Webを加速するHTTP/3」で、同社の奥一穂氏がHTTP/3の解説を行っています。 本記事では奥氏のセッションをダイジェストで紹介します。（本記事は「HTTP/3はどうやってWebを加速するか？ TCP、TLS、HTTP/2の問題とHTTP/3での解決策～Fastly奥氏が解説（前編）」の続きです） サーバプッシュの
QUICの実装はTCP並みの効率を実現できるか？ Fastly奥氏らがベンチマークを紹介
現在標準化が進められている次世代HTTPの「HTTP/3」は、トランスポートプロトコルとして「QUIC」と呼ばれる新しいプロトコルを採用します。 現時点のHTTPはトランスポートプロトコルとして「TCP」が採用されています。その上で、可能な限り高速な通信が行えるようにさまざまな工夫や最適化が進められてきました。そしてもうこれ以上高速にしようとすると、TCPそのものを改善していくべきだろう、というところまできたのです。 それがHTTP/3で「QUIC」が採用される大きな理由といわれています。 TCPは内部で輻輳制御や再送などを自動的に行うことで通信が確実に行われることを保証してくれる便利なプロトコルですが、それゆえに、確実に通信が行われるまで待つ必要があるために通信環境によっては遅くなりがち、などの側面があります。 そこでQUICは、TCPのような通信の保証がない代わりにリアルタイム性の高い
CORSでハマったことまとめ - pixiv inside [archive]
こちらは ピクシブ株式会社 Advent Calendar 2014 の12/16の記事です。 こんにちは、エンジニアの@dnskimoです。 先日、はじめてCORSを実装する機会があったので、覚書がてらまとめておきたいと思います。 CORSとは Cross-origin resource sharingの略です。 読み方は「コルス」でいいんでしょうか？ Same-Origin Policyに弾かれずに、異なるドメイン間でリソースを共有する仕組みです。 2014年1月にW3C勧告になり、JSONPに替わる方法として徐々に普及してきているようです（要出典）。 アクセスコントロールの仕様も定義されているので、特定のサイトからのみ利用可能なAPIを作る際などに便利です。 JSONPのような「裏ワザ」的な方法ではないところも個人的に好みです。 詳しいことはネット上に素晴らしい記事がたくさんあるので
![CORSでハマったことまとめ - pixiv inside [archive]](https://cdn-ak-scissors.b.st-hatena.com/image/square/5f6a93da881857fccf6161c1a2f6935458bfbb97/height=288;version=1;width=512/http%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fd%2Fdevpixiv%2F20141216%2F20141216151227.jpg)
CORSまとめ - Qiita
今更ですが、CORS (Cross-Origin Resource Sharing)を色々試していたら、思っていた以上に色々パターンがあることに気づいたので、改めてその扱い方についてまとめてみました。 そもそも 現在のWebブラウザでは、あるWebサイトが持つ情報が別の悪意あるWebサイトに悪用されるのを防ぐために、Same-Origin Policy(日本語では同一生成元ポリシー)が適用されます。 例えば、あるWebサイト https://guiltysite.com をブラウザで表示している時に、このWebページからXMLHttpRequest(以下、XHR)やFetch APIで別のWebサイト https://innocentsite.net からHTTP(S)でデータを読み込もうとすると、エラーになる、というわけです。 しかし、アクセス元が悪意あるWebサイトならともかく、データ
remote_addrとかx-forwarded-forとかx-real-ipとか - Carpe Diem
背景 ECSでNginxのコンテナをプロキシとして立てたところ、APIサーバのアクセスログのクライアントIPがNginxのコンテナIPになっていたのでその修正をしたのがきっかけです。 環境 Nginx 1.10.2 Docker1.12.1 構成 Client -> ELB -> Nginx -> API という構成とします。 ネットでよく見る情報 set_real_ip_from 172.31.0.0/16; real_ip_header X-Forwarded-For; を追加する、とか proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; を追加する、とかどれがどれだか分かりにくいので１つ１つ説明していきます。 用語説明 remote_
セキュリティ対策としての Cache-Control ヘッダについて - 理系学生日記
今日はブラウザのキャッシュ制御の話。キャッシュについては主に性能面で語られて、情報漏洩に繋がる重要な制御であることは見逃されがちです。 CDN切り替え作業における、Web版メルカリの個人情報流出の原因につきまして | メルカリエンジニアリング 情報漏洩自体はよくないことで、被害にあってしまった人はそんなこと言ってられないけれど、その原因を包みかくさず公開することで他山の石というか、間違いなく日本のセキュリティ意識は向上すると思います。 ぼく自身も、みなさんも、そろそろ Cache-Control: no-cache, no-store, must-revalidate しとけば良いんやろ、というゴミのような意識を改善しなければならないということで、ここにキャッシュについてまとめてみます。 Cache の種類 ブラウザで関連するキャッシュには主に 2 つほどあります。 private cac
HTTP キャッシュを使用して不要なネットワーク リクエストを防止する | Articles | web.dev
HTTP キャッシュを使用して不要なネットワーク リクエストを防止する コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 ネットワーク経由でのリソースの取得には時間とコストがかかります。 サイズの大きいレスポンスの場合、ブラウザとサーバーの間で何度もやり取りする必要があります。 重要なリソースがすべてダウンロードされるまで、ページは読み込まれません。 限られたモバイルデータ プランでサイトにアクセスしている場合、不要なネットワーク リクエストはすべてユーザーのお金の無駄使いです。 不要なネットワーク リクエストを回避するにはどうすればよいでしょうか。ブラウザの HTTP キャッシュは防御の最前線ですこれは必ずしも最も強力で柔軟なアプローチではなく、キャッシュに保存されたレスポンスの存続期間を制御することは限られていますが、効果的であり、すべてのブラウザでサポ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
