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）」である場合、「安全」であるとみなされます。つまり、クライアントがターゲットリソースに安全なメソッドを適用した結果として、オリジンサーバーにいかなる状態変更も要求せず、期待もしません
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.
- リクエストメソッドは、そのメソッドを使用した複数回の同一のリクエストがサーバーに及ぼす意図された効果が、単一のリクエストの効果と同じであれば、「冪等」であるとみなされます
サポートの可否
| 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"
- キャッシュがレスポンスを保存して使用するためには、関連するメソッドが明示的にキャッシュを許可している必要があり、かつ、レスポンスが後続のリクエストを満たすために使用できる条件を詳細に明記する必要があります
サポートの可否
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 | ✕ |
参考資料