Note

私は韓国でプログラミングと日本語を勉強している学生です

日本語がまだ不慣れなため、翻訳には機械翻訳を使用しました。もし不自然な点や間違いがありましたら、ご指摘いただけると幸いです

はじめに

HTTPの仕様（スペック）には、次のような3つの共通メソッド属性があります。

Safe Methods（安全性）
Idempotent Methods（冪等性）
Methods and Caching（キャッシュ）

安全性 (Safe)

安全 (Safe) の定義

危険ではない、安全な
安心できる

HTTPにおけるSafeとは？

Request methods are considered "safe" if their defined semantics are essentially read-only; i.e., the client does not request, and does not expect, any state change on the origin server as a result of applying a safe method to a target resource.

リクエストメソッドは、その定義された意味が本質的に「読み取り専用（read-only）」である場合、「安全」であるとみなされます。つまり、クライアントがターゲットリソースに安全なメソッドを適用した結果として、オリジンサーバーにいかなる状態変更も要求せず、期待もしません

安全性の簡単な定義

GET /users/1

次のようなHTTPを呼び出しても、単に読み取るだけで、サーバーデータの変更は一切ありません
つまり、読み取り専用であるそのリクエストは「安全」であるとみなされます

HTTPでSafeと呼ばれる理由

reasonable use of a safe method is not expected to cause any harm, loss of property, or unusual burden on the origin server.

合理的な使用が、害を及ぼしたり、損失を引き起こしたり、オリジンサーバーに異常な負担をかけたりしないことが期待されます
つまり、サーバーに害がない（安全である、安心できる） → safe

サポートの可否

Method	Safe
GET	○
HEAD	○
OPTIONS	○
TRACE	○
POST	✕
PUT	✕
DELETE	✕
CONNECT	✕
PATCH	✕

Safeを区別する理由

ウェブクローラーが自由にGETリクエストを送信できます
ブラウザがページを事前に読み込む（pre-fetch）ことができます
キャッシュの最適化が可能です

注意事項

GET /page?do=delete

次のようにすると、クローラーやプリフェッチがデータを削除してしまう可能性があるため注意が必要です

冪等性 (Idempotent Methods)

冪等 (Idempotent) の定義

最初に実行した後、複数回適用しても結果が変わらない操作、または機能、属性
冪等な操作の結果は、一度実行しても複数回実行しても同じでなければなりません

HTTPにおける冪等性とは？

A request method is considered "idempotent" if the intended effect on the server of multiple identical requests with that method is the same as the effect for a single such request.

リクエストメソッドは、そのメソッドを使用した複数回の同一のリクエストがサーバーに及ぼす意図された効果が、単一のリクエストの効果と同じであれば、「冪等」であるとみなされます

冪等性の簡単な定義

PUT /users/1 {name : john} 
PUT /users/1 {name : john}
PUT /users/1 {name : john}
PUT /users/1 {name : john}

何度送っても結果は「john」で同じです。これを「冪等」といいます
つまり、1回送っても数十回送っても、サーバーの状態は同じです

サポートの可否

method	idempotent
GET	○
HEAD	○
OPTIONS	○
TRACE	○
PUT	○
DELETE	○
POST	✕
CONNECT	✕
PATCH	✕

PUT、DELETE + すべてのSafeメソッド = Idempotent（冪等）です

DELETEの冪等性

DELETE /users/1 -> 200 OK
DELETE /users/1 -> 404 Not Found

これは「冪等」です
サーバーの「状態」が重要です。したがって、サーバーの最終状態は常に「データなし」で同じです。つまり、冪等です

PATCHが冪等ではない理由

PATCHは部分的な修正を担当するため、冪等である場合もあれば、冪等ではない場合もあります

PATCH /users/1 { "tall": 161 }
PATCH /users/1 { "tall": 161 }
PATCH /users/1 { "tall": 161 }

上記のような場合、継続してリクエストを送信しても、身長は常に161です
つまり、このような場合は冪等です

PATCH /users/1 { "operation": "add", "tall" : 2} // +2 
PATCH /users/1 { "operation": "add", "tall" : 2} // +2
PATCH /users/1 { "operation": "add", "tall" : 2} // +2

上記のように継続してリクエストする場合、身長は2cmずつ伸びることになります
つまり、サーバーの状態が変化し続けるため、これは冪等ではありません

POSTが冪等ではない理由

POST /board/write {"title" : "今日の日記"} // id 1
POST /board/write {"title" : "今日の日記"} // id 2
POST /board/write {"title" : "今日の日記"} // id 3

上記のように継続してリクエストする場合、今日の日記が + n個作成されます
つまり、サーバーの状態が変化し続けるため、これは冪等ではありません

PUTの冪等性

PUT /board/1 {"title" : "今日の日記修正"} // id 1
PUT /board/1 {"title" : "今日の日記修正"} // id 1
PUT /board/1 {"title" : "今日の日記修正"} // id 1

上記のように継続してリクエストを送っても、idは常に1であり、タイトルは「今日の日記修正」です
つまり、サーバーの状態が変わらないため、冪等です

Methods And Caching（以下：キャッシュ）

Method

方法、方式
メソッド

Caching

コンピュータにおけるキャッシュ

HTTPにおけるCaching

"For a cache to store and use a response, the associated method needs to explicitly allow caching and to detail under what conditions a response can be used to satisfy subsequent requests"

キャッシュがレスポンスを保存して使用するためには、関連するメソッドが明示的にキャッシュを許可している必要があり、かつ、レスポンスが後続のリクエストを満たすために使用できる条件を詳細に明記する必要があります

キャッシュの簡単な整理

GET /users/1 -> { name : "john"} 
キャッシュ保存
GET /users/1 (サーバーに行かず、すぐにjohnを返す)

後でまた使うものをあらかじめ保存しておきます
これにより、サーバーの負担を減らし、応答速度を速くします

サポートの可否

This specification defines caching semantics for GET, HEAD, and POST, although the overwhelming majority of cache implementations only support GET and HEAD.

この仕様は、GET、HEAD、POSTに対するキャッシュのセマンティクスを定義していますが、圧倒的多数のキャッシュ実装はGETとHEADのみをサポートしています

method	caching
GET	○
HEAD	○
POST	△
PUT	✕
DELETE	✕
PATCH	✕
OPTIONS	✕
TRACE	✕
CONNECT	✕

参考資料