8つのHTTPメソッドの特徴と性質まとめ

8つのHTTPメソッド

メソッド 意味
GET リソースの取得
POST リソースの作成、その他の処理
PUT リソースの更新
DELETE リソースの削除
HEAD リソースのヘッダを取得
OPTIONS リソースがサポートしているメソッドの取得
TRACE 自分宛にリクエストメッセージを返す試験
CONNECT プロキシ動作のトンネル接続への変更

これらのうちGET、POST、PUT、DELETEの4つが「CRUD」の性質を満たすため、代表的なメソッドです。
(CRUD = Create, Read, Update, Delete)

また最後の2つである、TRACEとCONNECTはほとんど使われていません。
ですので、他の6つについて見ていきます。

GET

リソースの取得を行います。
最も基本的なメソッドです。

# リクエスト  
GET /reports HTTP/1.1  
Host: sample.com  

# レスポンス  
HTTP/1.1 200 OK  
Content-Type: text/html; charset=utf-8  

<!doctype html>  
<html>  
<head>  
略     
</head>  

<body>  
<div>  
    <h1>リポート一覧</h1>  
    <ul>  
      <li><a href="/reports/1">リポート1</a></li>  
      <li><a href="/reports/2">リポート2</a></li>  
    </ul>  
</div>  
</body>  
</html>  

POST

リソースの作成を行います。
GETに次いで利用頻度の高いメソッドです。

# リクエスト  
POST /reports HTTP/1.1  
Host: sample.com  

Hello World!!  

# レスポンス  
HTTP/1.1 201 Created  
Content-Type: text/plain; charset=utf-8  
Location: http://sample.com/reports/3  

Hello World!!  

また、他のメソッドでは対応できない処理の実行もできます。

例えば、検索時のURLを考えてみましょう。
http://sample.com/search?q={キーワード}
上記のような感じになりますがキーワードが長すぎるとき、実装側でURLの長さに制限がある場合などはGETメソッドでは対応できなくなります。

そんなとき、POSTメソッドはこのクエリパラメータをリクエストボディに含めることができます。

# リクエスト  
POST /search HTTP/1.1  
Host: sample.com  

q=long+long+long+long+search+keyword...  

このように、POSTメソッドは他のメソッドでは対応できない時に使用できる、なんでもできるメソッドです。

PUT

リソースの更新を行います。

# リクエスト  
PUT /reports/3 HTTP/1.1  
Host: sample.com  
Content-Type: text/plain; charset=utf-8  

HELLO WORLD??  

# レスポンス  
HTTP/1.1 200 OK  
Content-Type: text/plain; charset=utf-8  

HELLO WORLD??  

DELETE

リソースの削除を行います。
DELETEメソッドはレスポンスボディを持ちません。
ですので、レスポンスヘッダのみが返ってきます。
ステータスコードは200 OKまたは204 No Contentになります。

# リクエスト  
DELETE /reports/3 HTTP/1.1  
Host: sample.com  

# レスポンス  
HTTP/1.1 200 OK  

GETとよく似たメソッドですが、GETと違ってリソースのヘッダのみを取得します。
この性質を利用することで、ネットワークの帯域を節約しながらリソースの大きさや更新日時を取得できます。

# リクエスト  
HEAD /reports/3 HTTP/1.1  
Host: sample.com  

# レスポンス  
HTTP/1.1 200 OK  
Content-Type: text/html; charset=utf-8  

OPTIONS

リソースがサポートしているメソッド一覧を返します。

# リクエスト  
OPTIONS /reports HTTP/1.1  
Host: sample.com  

# レスポンス  
HTTP/1.1 200 OK  
Allow: GET, HEAD, POST  


# リクエスト  
OPTIONS /reports/3 HTTP/1.1  
Host: sample.com  

# レスポンス  
HTTP/1.1 200 OK  
Allow: GET, HEAD, PUT, DELETE  

べき等性と安全性について

べき等とは「ある操作を何回行っても結果が同じこと」を意味する数学用語です。
HTTPメソッドの中にはべき等性を持つものと持たないもの、安全性を持つ物持たないものがそれぞれ存在します。

まとめると以下のようになります。

メソッド 性質
GET, HEAD べき等かつ安全
PUT, DELETE べき等だが安全ではない
POST べき等でも安全でもない

以下解説していきます。

べき等かつ安全

GETとHEADに当たります。
GETで取得するリソースは何回取得しようと同じです(べき等性)。
また取得するだけなので、元のリソースが変化することはありません(安全性)。

ですので、GETとHEADは「べき等かつ安全」と言えます。

べき等だか安全ではない。

PUTとDELETEに当たります。

まず、PUTは何回同じリクエスト送ろうと更新した結果が返ってきます。

# リクエスト  
PUT /reports/3 HTTP/1.1  
Host: sample.com  
Content-Type: text/plain; charset=utf-8  

HELLO WORLD??  

# 途中で通信エラーが起きた  
# もう一度送る  

# リクエスト  
PUT /reports/3 HTTP/1.1  
Host: sample.com  
Content-Type: text/plain; charset=utf-8  

HELLO WORLD??  

# レスポンス  
HTTP/1.1 200 OK  

PUTを二回送信しても、一回送信した時と結果は同じです。

また、DELETEも同様に何回同じリクエスト送ろうがリソースを削除した結果が返ってきます。

# リクエスト  
DELETE /reports/3 HTTP/1.1  
Host: sample.com  

# レスポンス  
HTTP/1.1 200 OK  

# もう一度送る  

# リクエスト  
DELETE /reports/3 HTTP/1.1  
Host: sample.com  

# レスポンス  
HTTP/1.1 404 Not Found  

二回目は404 Not Foundが返ってきました。
しかし「リソースが削除されている」という結果は一回目の時と同じなので、べき等であると言えます。

このようにPUTとDELETEは同じリクエスト複数回送信しても結果が変わらないという性質があるため、クライアントは送信の重複を恐れることなく、何度でもPUTとDELTEを送信できます。

安全でもべき等でもない

POSTに当たります。
POSTだけはリクエストの結果として何が返ってくるかは分かりません。
ですので、クライアントはPOSTを複数回送ることに慎重にならなければなりません。
POSTを二回送信してしまい、二重注文のような現象が起こる可能性があるからです。

まとめ

たった8つのメソッドでリソースを操作するのがHTTPです。
この非常に少ないメソッドがRESTの統一インターフェース制約です。
メソッドを限定したからこそプロトコルがシンプルになり、Webの成功へと至ったと言われています。

最後に以下の文を引用して終わります。

GETに隠された安全性、PUTとDELETEのべき等性、そしていざとなったらなんでもできるPOST。
HTTPはそれぞれのメソッドに合った性質と拡張性を備えた、優れたプロトコルです。

参考にした書籍等

Webを支える技術