Real World HTTP の読書感想文
tl;dr
オライリーのReal World HTTPを読みました
全11章で構成されていて、HTTPの歴史に沿ってHTTPの機能やwebの世界でよく使われる技術 (暗号化、レスポンシブデザインなど)を紹介しています
HTTP/1.0のメインの機能とHTTP/1.1、HTTTP/2.0に変わる際に何が変わったのかについて詳しく説明してあり、実際にgoを使ってHTTPサーバーとクライアントを用意しHTTP通信を行うハンズオンも用意してあるため理解はしやすかったです
ただ本の構成としてはコア機能として4つありますと言いつつ、順番に紹介するわけではなく追加でいくつか機能が書かれていて読みにくさは感じました
ブラウザからリクエストを送った時何が起こっているのか、体系的にHTTPについて勉強したいのであれば網羅的に書いてあるのでいいと思います
読んだ本
普段Webエンジニアとして仕事をしているくせに、HTTPについてきちんと理解しているかと言わたら自信を持ってyesとは言えないなと思って勉強の為に読みました
1章
HTTP/1.0の基本の4つの要素
- メソッドとパス
- ヘッダー
- ボディ
- ステータスコード
メソッドとパス
HTTPリクエストを送る時にはメソッドとpathを指定します
メソッドは以下のようなもの
- GET: サーバーに対して、ヘッダーとコンテンツを要求
- HEAD: サーバーに対して、ヘッダーのみを要求
- POST: 新しいドキュメントを投稿
パスはサーバーの中のどのファイルをリクエストしたか示すものです
/index の時はリクエストを受け取ったサーバーのrootディレクトリ直下のindexというファイルを要求しています
ヘッダー
ヘッダーはリクエストヘッダーとレスポンスヘッダーの２種類があります
リクエストヘッダーはブラウザからサーバーへ送るリクエストに含まれるヘッダーで先ほどのメソッドとパスの他に、host (どこのサーバーへ送るか)、User-Agent (リクエスト送信元のブラウザの種類)などが記載されています
レスポンスヘッダーはサーバーからブラウザへ送るレスポンスに含まれるヘッダーで、3桁のステータスコード、Content-Length (レスポンスのサイズ)、Content-Type (送られてきたレスポンスのファイルの種類)が記載されています
ボディ
ヘッダーの下に1行空行を挟み、それ以下は全てボディと見なされる
リクエストにもレスポンスにもボディを含むことができる
ちなみにGETリクエストにもボディを含むことができるが、サーバー側で無視される
ステータスコード
レスポンスヘッダーに含まれる3桁の数字
ステータスコードの大まかな分類
- 100番台: 処理中の情報の伝達
- 200番台: 成功時のレスポンス
- 300番台: サーバーからクライアントへの命令。リダイレクトやキャッシュの利用を支持
- 400番台: クライアントから送られたリクエストにおかしなことがある場合のレスポンス
- 500番台: サーバー内部でエラーが発生した場合のレスポンス
1章の感想
HTTP/0.9では何ができてHTTP/1.0ではどう変わったのかという流れで進めながらHTTPの基本を紹介しています
冒頭で基本の4要素として
- メソッドとパス
- ヘッダー
- ボディ
- ステータスコード
を紹介しているわりに、それぞれについて詳しく説明するみたいな構成ではないので読みづらかったです
第2章
フォームの送信方式
x-www-form-urlencoded
keyとvalueの組み合わせをencodeして送信する
テキストのみ
multipart/form-data
ファイルの送信が可能
区切り文字ごとにファイルなのか文字列なのかContent-Type (正確にはContent-Disposition)を指定
クッキー
サーバーがブラウザにデータを保存しておく仕組み
クライアント側で削除や変更が可能なので永続的である必要のあるデータの保存には向かない
セッショントークンの保存などに用いられる
セッション
サーバー側で認証が済んだ後に、トークンを発行してその後の認証はidとpasswordを使わない仕組み
クッキーに含まれるトークンとセッションサーバーに保存されたトークンで認証する
プロキシ
ブラウザとサーバーの仲介役となるサーバー
cssやjsなどの静的ファイルをプロキシサーバーから返すことでレスポンスを早くすることができる
キャッシュ
ブラウザ側ですでにダウンロード済みのコンテンツがありダウンロード後変更がなければ、サーバーから再ダウンロードすることなくページを表示する仕組み
Headerによって時間などを細かく制御可能
2章の感想
フォームの送信、クッキーやセッションの話など普段ブラウザとサーバーとの通信で使われているものの紹介
この章は一つ一つ丁寧な説明があって、例えばmultipart/form-dataの構造はどうなっているかとか
キャッシュのコントロールはどのように行われているかなど詳細に書いてあってわかりやすかったです
3章
ハンズオンのため省略
4章
HTTP/1.0からHTTP/1.1への変更点
- 通信の高速化
- TLSによる暗号化通信のサポート
- 新メソッドの追加
- プロトコルのアップグレード
- 名前を使ったバーチャルホストのサポート
- サイズが事前にわからないコンテンツのチャンク転送エンコーディングのサポート
通信の高速化
以下の二つの仕組みを使って高速化されている
Keep-Alive
TCP/IPの通信を高速化する仕組み
Keep-Aliveを使わない場合は一つのリクエストごとに通信を閉じる
Keep-Aliveを使う場合、リクエストヘッダーに以下のヘッダーが追加される
Connection: Keep-Alive
そしてクライアントとサーバーのどちらが以下のヘッダーを付与して接続を切るかタイムアウトするまで接続を継続する
Connection: Close
クライアントとサーバーとの間で連続で通信を行う際に毎度コネクションを貼らなくていいので通信を高速化することができる
パイプライニング
HTTP/1.0ではクライアントがリクエストを送りサーバーからレスポンスが返ってくるのを待ってから次のリクエストを送っていた
パイプライニングは最初のリクエストが完了する前に次のリクエストを送信し、「レスポンスが返ってくるまで次のリクエストを待つ」この時間を短縮する
TLS
通信を暗号化する仕組み
共通鍵方式と暗号鍵方式の両方を使用して通信を暗号化する
具体的にはクライアント側で共通鍵を作成し、公開鍵で暗号化する
それをサーバー側で秘密鍵で復号し、その後の通信は共通鍵で暗号化して行う
公開鍵の安全性の高さと共通鍵の暗号、復号にかかる時間の短さの両方の良さを活かしている
PUTメソッドとDELETEメソッドの標準化
HTTP/1.0ではオプションだったPUTとDELETEが標準化されることでデータを扱う基本の４メソッド (CRUD: Create, Read, Update, Delete)が揃った
プロトコルのアップグレード
HTTP以外へのプロトコルへのアップグレードができるようになった
HTTPからTLSを使った安全な通信へのアップグレード
HTTPからWebSocketを使った双方向通信へのアップグレード
HTTPからHTTP/2へのアップグレード
バーチャルホストのサポート
ドメイン名 + ポート番号をサーバーが受け取れるようになり、一台のウェブサーバーで複数のウェブサービスを運用できるようになった
チャンク
いわゆるストリーミング方式と呼ばれる、全体を一括で送信するのではなく、データを小分けにして送信するチャンク方式がサポートされた
４章の感想
この章ではかなりページを割いてTLSについて解説されていました
hash化、SSLサーバ証明書、鍵交換アルゴリズムなど一つ一つわかりやすく説明してあったのでまた別の記事で自分なりに整理して書きたいと思います
第1章とかに比べてかなり読みやすかったです
5章
この章ではHTTP/1.1以降に追加された様々な機能について紹介されています
ファイルのダウンロード
ブラウザがファイルをどのように処理するかは、ファイルの拡張子ではなくサーバの送るMIMEタイプで判断されます
以下のようなヘッダーが含まれる場合、ブラウザはfilenameで指定された名前でファイルを保存します
Content-Disposition: attachment; filename=filename.xlsx
Content-Dispositionヘッダーによるダウンロードの仕組みはHTTP/1.1の初版から2年後のRFC2616で言及されました
ダウンロードの中断、再開
HTTP/1.1ではダウンロードが中断した時に、途中から再開する方法が提供されています
サーバー側が範囲指定ダウンロードをサポートしている場合、Accept-Rangesヘッダーを付与することで範囲指定が可能です
Accept-Ranges: bytes
複数範囲を指定することもできます
Accept-Ranges: bytes=100-399, 500-799
これを使うとContent-Type=multipart/byterangesというヘッダーが含まれたレスポンスが返ってきます
multipart/form-dataがリクエストに複数のデータを含めるのに使われるのに対し、multipart/byterangesはレスポンスに複数のデータを含めるのに使用されます
XMLHttpRequest
XMLHttpRequestはJavaScriptから使用できるcurlコマンドのようなもので、JavaScriptからサーバーへリクエストを送ることができます
ブラウザ - サーバー間でリクエストを送ると、レスポンスが返ってきた時点でブラウザがリロードされてしまいますが、JavaScript - サーバー間でリクエストを送るとリロードすることなく新たなデータをサーバーから取得することができます
この機能を使い、画面クリアせずにウェブページを読み込んだり、時間やタイミングをずらしてなんども更新できるアーキテクチャのことをAjax (Asynchronous JavaScript + XML)と呼びます
Geo-Location
通信してきたクライアントの物理的な場所を測定する方法
以下の2パターンがあります
クライアント自身が場所を得る情報
スマートフォンであればGPS情報を使って位置情報を返すことができます
またWifiのアクセスポイントとユニークなIDを保存しているサーバーにクライアントからリクエストを投げることで位置情報を知ることもできます
サーバーがクライアントの場所を推測する方法
これはGeoIPと呼ばれ、IPアドレスから推測します
IPアドレスは地域ごとに管理団体があり、企業やプロバイダーに割り当てを行います
どのプロバイダーがどのアドレスどこへを割り当てているかはわからないため、地道にデータを集めてマッピングしたサービスを使用することになります
X-Powerd-Byヘッダー
RFCの規格にはない独自ヘッダー
多くのサーバーがシステム名を返すのに使用しており、デファクトスタンダードになっています
ただ、セキュリティの面でサービスの脆弱性を晒すことになりかねないので、OSバージョンなどサーバー名以外の余計な情報は入れてはいけないと決められています
リモートプロシージャコール
別のコンピュータの機能を、あたかも自分のコンピュータ内であるかのように呼び出しを行い、必要に応じて返り値を受け取る仕組み
XML-RPC 、SOAP、JSON-RPCと行った規格がある
WebDAV
WebDAVは正確にはHTTP/1.1には含まれていません
HTTP/1.1を拡張することで分散ファイルシステムとして使えるようにしたものです
HTTP/1.1のPOST、GET、PUT、DELETEだけではファイルシステムとして機能が足りないので以下のようなメソッドを追加しています
COPY、MOVE、MKCOL (ディレクトリ作成)、PROPFIND (要素一覧をプロパティとして取得)、LOCK/UNLOCK (複数人の編集によるデータの不整合を防ぐ)
ウェブサイト間で共通の認証、認可プラットフォーム
様々なWebサービスが登場するにつれ、サービスごとにID/Passwordを作成、保管することがユーザーにとって負担となってきました
そこで外部の認証基盤に相乗りする仕組みが開発されてきました
サービス側としても認証基盤を一から実装しなくて済みますし、ユーザーも新たにpasswordを覚えなくてすみます
以下が代表的な例です
５章の感想
かなりの重量感のある章でしたw
ただ紹介されているるのは現在多く使われている技術がメインなので面白く読むことができました
恥ずかしながら名前は知ってたけどJSからサーバーへの通信=XMLなのはわかってなかったなあ
６章
ハンズオンのため省略
7章
この章ではHTTP/2とその他の新しい世代のプロトコルについて紹介されています
HTTP/2
HTTP/1.1からHTTP/2の大きなアップデートは以下の3つです
- ストリームを使ってバイナリデータを多重に送受信する仕組みに変更
- ストリーム内での優先順位設定や、サーバーサイドからデータ通信を行うサーバーサイドプッシュを実装
- ヘッダーの圧縮
HTTP/2の目的は通信の高速化です
HTTP/1.1とは完全に異なったプロトコルであるため、TLS内に作られたプロトコル選択機能を使い丸ごと通信方式を切り替えます
そのため後方互換性の問題が起きにくくなっています
ストリーム
HTTP/2では各データはフレームと呼ばれる単位で送受信が行われます
HTTP/1.1までは1つのリクエストがTCPのソケットを占有してしまうため、２−6本のTCP接続を行なって並列化していました
HTTP/2では1本のTCP接続の内部にストリームという仮想のTCPソケットを作って通信を行います
ストリームがないときは新しいTCP説僕を行うたびにサーバーとクライアントでハンドシェイクを行い、並列化を行なっていました
ストリームを使うことで、ハンドシェイクなしに簡単に接続の並列化を行うことができるようになりました
サーバープッシュ
優先度の高いコンテンツをクライアントからリクエストされる前に送信できる仕組み
ただ双方向通信ではないので、あくまでクライアントがリクエストを送信するまではデータがプッシュされていることは検知できません
コンテンツを事前にキャッシュしておき、リクエストを送るタイミングですぐにダウンロードできるという仕組みです
ヘッダーの圧縮
HTTP/2ではヘッダーを圧縮できます
ヘッダーの圧縮で使用されるHPACKという方式は、事前に辞書を持っておきます
HTTPのヘッダーは同じ名前がよく出現するためヘッダー名とヘッダー値をあらかじめ辞書に持っています
Fetch API
XMLHttpRequestのようなJavascriptから用いるサーバーアクセスを行う関数
JavascriptのPromiseに準拠しています
キャッシュの制御やリダイレクトの制御を行うことができ、またPWAのライフサイクルや通信内容をコントロールするService Workerの中からも利用することができます
Server-Sent Events
一度のリクエストに対して、サーバーから複数のイベント送信を行う機能
Chunked形式で送信し、クライアント側ではJavascriptがイベントをlistenします
Web Socket
クライアントとサーバの間でオーバーヘッドの小さい双方向通信を実現する機能
1対1の通信のため送信先の情報などは持っていません
HTTPとは違い、サーバーのメモリ上にデータを持った状態で通信するステートフルな通信であるため普通のロードバランサーは使えないので注意が必要です
Web RTC
Web RTC (Web Real-Time Communication)とはブラウザとサーバーではなく、ブラウザとブラウザの通信で使われる基盤です
基本的にはビデオ通話や画面共有などに使われ速くデータを届けることが必要になるため、TCPではなくエラー処理や再送処理を行わないUDPをメインで使います
TCPとUDPの違いについては以下のリンクの記事でまとめています
HTTP ウェブプッシュ
ウェブサイトにスマートフォンアプリケーションのような通知機能を提供する仕組み
プッシュサービスはChromeとFireFoxが対応しています
流れとしては
- ブラウザがpushサービスに購読を申し込む
- アプリケーションサーバーがプッシュサービスにメッセージを投稿
- ブラウザがプッシュメーセージを受信
となります
実際にメッセージを受信するのはService Workerです
７章の感想
HTTP/2以外の機能がバラエティーに富んでいて一度で理解するのはしんどいなと思いました 特にRTCの部分はめちゃめちゃ短くまとめちゃいましたが、色々なユースケースに対してどんどん新しい機能が追加されていて読んでて頭が追いつかなかったです ただ新しいプロトコルだけあって身の回りに使われているものが多くイメージはわきやすいと感じました
８章
８章ではブラウザとサーバーの通信の話ではなく、HTTP/2の登場前後で現れた検索エンジンやソーシャルメディアが理解するプロトコルの紹介です
レスポンシブデザイン
昔はUser Agentをみてデザインを切り替えるだけで十分でした
近年はPCとスマホ、タブレットの縦と横などがあり、様々なデバイスで適切なレイアウトの表示を可能にするのがレスポンシブデザインです
cssのmedia queryを使用することでデバイスの幅にあわせてstyleを変更することができます
セマンティックウェブ
ウェブで表面的な「テキスト」「文書」だけでなく「意味」を扱おうという運動がセマンティックウェブです
セマンティックウェブもオープングラフプロトコルもAMPも人間向けの情報ではなく、他のシステムにウェブサイトのメタ情報を伝えるための機能です
RDF (Resource Description Framework)
XMLを使ってURIで識別されるエンティティ間の関係性を記述するものです
ウェブサイトの記述はHTMLなのでRDFを直接埋め込むことはできず、ベージ外にリソースをおきます
ダブリンコア
大抵のウェブリソースは誰かの著作物であることが多いので著作権、著者、ID、出版社などの情報をメタデータとして埋め込むことができます
RSS
RSSはウェブサイトの更新履歴のサマリーに関するボキャブラリーです
ブログやウェブサイトを更新すると、ブログエンジンやコンテンツ管理システムが自動的に更新をしてくれ、RSSファイルに新しい順に新規コンテンツのサマリーが格納されます
ウェブサイトをブラウザで巡回しなくても、リーダーが登録したRSSの更新チェックを行い、未読のエントリーを集めて効率よく閲覧できるようにしてくれます
オープングラフプロトコル
twitterとかに記事を貼り付けると展開して画像や本文の一部を表示してくれる機能
ページ内にSNS向けの情報をメタタグとして記述する
以下の情報がよく使われる
タイトル
種類
URL
画像
引用ページに貼り付けるテキスト
ちなみにTwitterにはオープングラフプロトコルを拡張したTwitterカードという仕組みが用いられている
AMP
モバイル高速化のための仕組み
AMPに準拠したモバイル用の軽いウェブページを作成することでレスポンスタイムを速くすることができます
また、検索エンジンが情報収集のために用いるプログラムであるクローラーがAMPであるコンテンツを発見すると、GoogleのCDNサーバーにコンテンツをコピーします
ユーザーがモバイルでページにアクセスしようとした場合、GoogleのCDNサーバーからコンテンツが配信されるため普通にサーバーからダウンロードするよりも高速にレスポンスを返すことができます
８章の感想
レスポンシブデザインはかなり身近な言葉なので割とわかっていましたが、オープングラフプロトコルは名前は全く知りませんでした
ただ蓋を開けてみるとSNSがこれだけ使われている現代で見ない日はない技術で、あーこういう風に表示されてたのかーという面白みがありました
Real World HTTPもずいぶん読み進めましたがやっぱり後半の方が身近な話が多くて頭に入って来やすいですねw
９章
ハンズオンのため省略
10章
この章ではブラウザのセキュリティについて説明されています
クロスサイトスクリプティング (XSS)への対策
クロスサイトスクリプティングとはユーザーが入力するフォームなどに悪質なスクリプトを入力する攻撃方法です
攻撃者がJavascriptなどのスクリプトを入力し、サービス側が何のフィルタリングもせずにそれをHTMLとして出力していると、ブラウザ上でスクリプトが実行されてしまいます
クロスサイトスクリプティングは他の攻撃の起点となり得ます
例えばクッキーにアクセスされると他のサーバーに送信されクッキー情報が漏洩しますし、セッショントークンが盗まれるとログインユーザーになりすまされてしまいます
対策としては以下のものがあります
ヘッダーにhttpOnly属性を付与する
これを行うとJavascriptからクッキーにアクセスできなくなるためクロスサイトスクリプティングによるクッキー漏洩を防ぐことができます
X-XSS-Protectionヘッダーを設定
X-XSS-Protectionヘッダーを使うとHTMLのインラインでスクリプトタグを使っているケースなど明らかに怪しいパターンを検出します
Content-Security-Policyヘッダーを設定
Content-Security-Policyヘッダーはウェブサイトで使える機能を細かくON/OFFできる仕組みです
例えばHTMLから読み込むリソースファイルのアクセス権を設定したりすることができます
Content-Security-Policyヘッダーは使用することでXSSに対する強力な防衛策となりますが、強すぎて正常な動作を妨害することもあります
段階的に移行していきたい場合はContent-Security-Policy-Report-Onlyヘッダーを使用することでチェックは行うが動作は止まらないという設定にすることができます
中間者攻撃 (MITM攻撃) への対策
中間者攻撃はプロキシサーバーが通信を中継するときに通信内容を抜き取られることで情報が漏洩してしまう問題です
中間者攻撃を避けるにはHTTPS (TLS)を使って、通信の内容を暗号化するしかありません
しかし、TLSが守るのはあくまで「通信経路」だけなのでサーバーに対するクラックやブラウザに対するXSSには注意が必要です
HSTS (HTTP Strict Transport Security)
HSTSは中間者攻撃に対するHTTPの仕組みの1つで、サーバー側から今後接続する場合はHTTPSで接続してくれと伝達する仕組みです
レスポンスヘッダーに Strict-Transport-Security というヘッダーと有効期限を指定して返します
ただ初回の通信はHTTPになってしまうのでGoogle Chromeではこのデータベースを最初から設定するため情報を集めています
ウェブサイトから申請しておくと最新のブラウザをダウンロードするだけで初回からHTTPS通信になります
HTTP公開鍵ピンニング
ブラウザ側で、初回にアクセスした際サーバーが送信してきた公開鍵を保存しておきます
2回目以降にサーバーが送ってきた証明書の公開鍵と手元で保存している公開鍵を照らし合わせ、サイトの証明書が不正に変更されていないことを検証します
セッションハイジャッキングへの対策
セッションハイジャッキングとはその名の通り、ウェブサービスのセッショントークンを盗み出し、ウェブサイトにログインする攻撃です
セッショントークンはクッキーに保存されブラウザからサーバーへ送信されるため、以下の方法でクッキーを漏洩しないようにするのが有効な手段です
クロスサイトリクエストフォージェリ (CSRF)への対策
クロスサイトリクエストフォージェリとは、本人の意図しないサーバーリクエストを、無関係のページやサイトから送らせる攻撃方法です
本人が意図せずともクッキーは発行されてしまうのでログイン状態となり、被害者の権限で操作の実行が可能になります
CSRF対策トークン
これはフォームを送信するときに、type: hiddenのinputタグにランダムなトークンを入力し、サーバー側で正しいトークンが含まれていないリクエストを拒否する仕組みです
ウェブアプリケーションフレームワークで提供されている仕組みをそのまま使用すればCSRF対策トークンが送信されるはずです
リスト型アカウントハッキングへの対策
脆弱なウェブサイトが不正侵入を受けて、ユーザーIDとパスワードが流出してしまい、同じメールアドレスとパスワードで他のサイトに登録していたユーザーの情報も漏洩してしまうというもの
もちろんサービスごとに異なるパスワードを使用するのが一番安全です
二要素認証
ID、パスワードに追加して本人しか知り得ないと期待されるコードを入力する認証方法
銀行のワンタイムパスワードやGoogle Authenticatorなどのアプリケーションを用いる場合が多いです
10章の感想
セキュリティに関してはあまり理解できていないので、主要な攻撃方法を知れたのはよかった
XSSやSQLインジェクションなどに実際に自分で対策をするとなると、この賞でも書かれてたけどやっぱりフレームワークのやり方に乗っ取るのが一番なんだろうなと思った
11章
この章ではRESTful APIについてブラウザの視点から説明されています
RESTful APIとは
REST (REpresentational State Transfer)は以下の特性を備えています
APIがウェブサーバーを通じて提供されている
GET /users/[ユーザーID]/repositriesのように、パスに対してメソッドを送ることでサービスを得る
URLはリソースの場所を表す表現であり、サービスの顔として大切である
必要に応じて、GETパラメータ、POSTのボディーなどの追加情報を送信することもある
RESTful APIとRPCの違い
- RPC
URLは1つで、リクエスト時にサービス名とメソッド名を渡す事で「何をするか」を指定します
別の言い方をすると、ウェブサーバーを通じて公開されている静的なオブジェクトのインスタンスをURLを通じて発見し、そのメソッドを呼美ます
HTTPのメソッドは全てPOSTです
- REST
RESTではリソースとメソッドに対応するURLが複数あります
ex. GET /users/:id、 POST /users、DELETE /users/:id
HATEOAS
HATEOAS (Hypermedia As The Engine Of Application Stat)はRESTの一部である「インターフェースの一般化」を仕様化したもの
リソース間の関連情報やリソースの操作のリンクをレスポンスに含める事で、リソースの自己記述力を向上させます
データに対する操作や関連するリソースへのリンクがレスポンスに含まれるため、完全なHATEOASが実現されていたとすると、クライアントはトップページを見ればそこからデータや操作を表すリンクのリストを得る事ができルため、APIの使用に関する知識がなくても、リンクをたどるだけでAPIの機能が十分使えるようになります
RESTful と RESTish
REST APIは階層化されたリソースをもち、HTTPのシンタックスとセマンティクスを守ったAPI構造を備えることを理想としています
現実には実装を進めていくうちに、URLに動詞が入ったり、バージョンが入ったり、本来はリソースの住所であるはずのURLに余計な情報が入ったりする事があります
RESTを提案したFielding氏は、このような設計のウェブサービスが「REST」を名乗ると激しく攻撃するようです
RESTの設計思想を守りきれない場合、RESTish (REST風) APIという呼び方をします
メソッド
REST APIではサービスが指定するメソッドを使用します
主に使われるのは以下の7つです
GET: データの取得
POST: データの新規作成
PUT: データの更新 (リソースがすでにある場合)
DELETE: リソースの削除
PATCH: 差分によるデータの更新 (リソースがすでにある場合)
HEAD: GETメソッドからボディーを抜いたもの
OPTION: 使えるメソッド一覧の取得
ちなみにリソースがない場合にPUTメソッドを使用するとPOSTの時と同様にデータが新規に作成されます
同じ更新処理であるPUTとPATCHの違いについては下のリンクの記事で説明しています
ステータスコード
ステータスコードはHTTPのレスポンスに含まれる３桁のコードです
百の位の数字で大まかな意味が変わります
100番台 (情報): 成功や失敗が決定する以前のステータスであることを示します
200番台 (成功): 正常終了したことを示します
300番台 (リダイレクト): リダイクレトやキャッシュの変更がない時の通知に使います
400番台 (クライアントエラー): URLが間違っているなどクライアントに起因するエラーが起こったことを示します
500番台 (サーバーエラー): サーバー側でエラーが発生したことを示します
11章の感想
REST APIについては、GETでリソースの情報を取得してPOSTで作成して、、といった基本的な仕様は知っていましたが、どのように定義されているか、RPCと何が違うのかといった部分については説明できなかったので、この章を読んで改めて確認する事ができました
また、自分が勉強用や、入社時の研修で作ったAPIサーバーはRESTishだったなあというのを認識しました
