7 章 HTTPメソッド 

今回は、「Webを支える技術」の本を読み、第7章 HTTPメソッドについて記述する。

<h3>7.1 HTTPメソッドとCRUD</h3>
HTTP1.1には、8つのメソッドがある。

| ------- | -------------------------------------------------------- | --- | 
| GET     | リソースを取得                                           |     | 
| POST    | 子リソースの作成、リソースへのデータ追加、そのほかの処理 |     | 
| PUT     | リソースの作成、更新                                     |     | 
| DELETE  | リソースの削除                                           |     | 
| HEAD    | リソースのヘッダー取得                                   |     | 
| OPTION  | リソースさサポートしてくるメソッド取得                   |     | 
| TRACE   | 自分宛にリクエストメッセージを返す                       |     | 
| CONNECT | プロキシ動作のトンネル接続への変更                       |     | 

特に、ポイントになるのが、上位の4つである。
これらを総称して、**CRUD**と呼ぶ。
深く、ここでは詳細に説明しない。各自で調べてほしい。

:::note warn
7.1~7.6まで省略しました。各自で気になるかたは書籍をチェック。

:::
　ここでは**個人的に**あまり見慣れない残りのメソッドについても説明する。


<h3>7.7 HEAD</h3>
HEADは、リソースのヘッダーのみを取得するメソッドである。

リクエスト
| ------------ | ------------------------- | --- | 
| HEAD         | /list/item1/HTTP/1.1      |     | 
| Host:        | example/com               |     | 


レスポンス
| ------------ | ------------------------- | --- | 
| HTTP1.1      | 200 OK                    |     | 
| Content-type | text/plain; charset=utf-8 |     | 


<h3>7.8 OPTIONS</h3>

OPTIONSは、リソースがサポートしてくれるメソッドの取得

リクエスト
| ------- | ------------- | --- | 
| OPTIONS | /list HTTP1.1 |     | 
| Host    | example.com   |     | 

レスポンス
| ------- | ---------------- | --- | 
| HTTP1.1 | 200 OK           |     | 
| Allow   | GET, HEAD., POST |     | 
レスポンスにある**Allow**は許可するメソッドです。
OPTIONS自体には、Allowを含めません。

OPTIONSを実装する場合、多くのWebアプリケーションでは
**リソースごとに対応してくるメソッドを返すように自前で実装しなければならない**

※ApacheのようなWebDevに対応したサーバでは設定ファイルで設定の挙動を修正できる。

<h3>7.10 条件つきリクエスト</h3>
HTTPメソッドと更新日時などのヘッダを組み合わせることでメソッドを実行するかどうか
をリソースの更新日時を条件にサーバが選択できるようになる。

これを「条件リクエスト」と呼ぶ。
EX,
日時条件を入れたい場合、以下のように書く。
if-Modified-Sinceヘッダを使う。


<h3>7.11 べき等性と安全性</h3>

べき等性は、「ある回数実行しても、*結果が同じであること*」を指す。
例えば、PUT, DELETEである。

安全性とは、「操作対象のリソースの状態を変化させないこと」。

<h4>HTTPメソッドの性質</h4>

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

べき等の例
絶対値やかけ算(0にどんな数字をかけても0)である


EX


```
リクエスト
| ----- | -------------- | --- | 
| GET   | /test HTTP 1.1 |     | 
| Host: | example.jp     |     | 
```


```
レスポンス
| ------------- | ------------------------------ | --- | 
| HTTP/1.1      | 200 OK                         |     | 
| Content-Type: | application/xml; charset=utf-8 |     | 

<test>test1</test>
```

PUTで更新してみよう!!!

```
リクエスト
PUT /test HTTP1.1
Host: example.jp
Content-Type: application/xml; charset=utf-8

<test>test2</test>
```

リクエストが成功した場合、<test>要素の内容が「test1」「test2」に更新される。
しかし、通信エラーが起こり。クライアントがレスポンス(200 OK)を確認できなかったらどうなるだろう?
その時は　、**再びリクエスト**が送られる。
同じPUTを複数回送信しても、**結果は一度送信した時と同じ結果である。**

<h4>DELETEべき等</h4>

```
リクエスト
| ------ | ------------- | --- | 
| DELETE | /test HTTP1.1 |     | 
| Host:  | example.jp    |     | 
```

```
レスポンス
HTTP 1.1 200 OK
```
上記のように、一度 削除されました。
もう一度、送ると、以下の結果が返る。

```
HTTP 1.1  404 Not Found
```

削除したので、 404 Not Foundが返る。リソースが削除されている結果のようである。
PUTやDELETEのような「べき等性」は何回送っても、同じ結果が返る。

<h4>GETとHEADもべき等、そのうえ安全</h4>

GETとHEADもべき等性である。あるリソースを何回送信しても、同じリソース状態なら結果は同一である。HEADの場合はリソースのヘッダのみが取得される。
さらに、GETとHEADは、安全という素晴らしい性質を持っている。PUTやDELETEはリソースの状態を変化させるが、GETとHEADはリソースの状態を変化させない。

<h4>安全でもべき等でもないPOST</h4>
POSTは安全でもべき等でもありません。すなわち、リクエストの結果で何が起きるかわからない。クライアントはPOSTを複数回送ることに新調しなければならない。

例えば、ショッピングサイトでブラウザの「戻るボタン」をクリックし、「もう一度送信しますか?」
という**ダイアログ**が出ることもある。これは、POST再送信しようとしている場合に送る。
このように、親切にダイアログ(警告)が出ればいいですが、ダイアログが出ない場合は
**自動的に再送信してしまい、二重注文のような問題が起こる可能性がある。**

<h3>7.12 メソッドの誤用</h3>
GETとHEADがべき等かつ安全で、PUTとDELETEがべき等であることはHTTPの仕様に定められている。しかし、WebサービスやWebAPIの設計を誤ると、これらのメソッドが安全出なくなったり、べき等でなくなったりする可能性がある。

<h4>GETが安全でなくなる例</h4>
GETの目的は、リソースの取得である。しかし、誤った目的でGETを利用しているWebAPIもある。例えば、以下の例である。

```
| ----- | --------------------------- | --- | 
| GET   | /resources/1/delete HTTP1.1 |     | 
| Host: | example.jp                  |     | 
```
この例では、「 /resources/1/」をdeleteするために、「http://example.jp/resources/1/delete」をGETしている。これはGETの目的である「リソース取得」を完全に無視した状態である。
**GETを正しく利用しているか否かの判断基準**は、GETの発行前後でリソースに変更が加えられているかどうかである。また、GETしようとしているリソースURIに、「update」や「delete」、「set」が含まれている場合も要注意である。

<h4>ほかのメソッドでできることにPOSTを誤用した例</h4>
ほかのメソッドでは対応できない処理をするPOSTは万能メソッドである。しかし、いきすぎると誤用につながる。POSTの誤用は他のメソッドが用意されているにもかかわらず、POSTでその機能を実現することである。
特に、GETやUPDATE、DELETEで実現できる機能を実現させようとしたら、**危険信号**である。GETやUPDATE, DELETEで実現できる素晴らしい性質が利用できなくなるからである。
一例. XML-RPCとSOAP。

<h4>PUTがべき等でなくなる例</h4>
トマトの価格を表現するリソース「http://example.jpp/tomato」を考える。この価格はプレーンテキストで表現している。

```
リクエスト
| ----- | --------------- | --- | 
| GET   | /tomato HTTP1.1 |     | 
| Host: | example.jp      |     | 
```


```
レスポンス
| ------------- | ------------------------- | --- | 
| HTTP 1.1      | 200 OK                    |     | 
| Content-Type: | text/plain; charset=utf-8 |     | 
100
```
現在価格は100円です。PUTでトマトの価格を更新してみる。


```
リクエスト
| ------------- | ------------------------- | --- | 
| PUT           | /tomato HTTP1.1           |     | 
| Host:         | example.jp                |     | 
| Conetnt=type: | text/plain; charset=utf-8 |     | 

+50
```

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

```
リクエスト
| ------------- | ------------------------- | --- | 
| PUT           | /tomato HTTP1.1           |     | 
| Host:         | example.jp                |     | 
| Conetnt=type: | text/plain; charset=utf-8 |     | 

+50
```

```
レスポンス
| ------------- | ------------------------- | --- | 
| HTTP 1.1      | 200 OK                    |     | 
| Content-Type: | text/plain; charset=utf-8 |     | 
200
```
トマトの値段が200円に変更されました。このように、PUTでリソースの相対的な差分を送信すると、PUTはべき等性ではなくなる。PUTでは、**なるべく完全な表現**を送信するようにしよう。この例では、価格を差分(+50)で表現するのではなく変更後の値「150」で表現するようにしよう。

以上が、HTTPメソッドについてである。
気になる方は手にとって読んでもらいたい。(一部抜粋)