Webを支える技術を読んで

#概要
前々から読みたいと思っていた[「Webを支える技術」](https://www.amazon.co.jp/Web%E3%82%92%E6%94%AF%E3%81%88%E3%82%8B%E6%8A%80%E8%A1%93-HTTP%EF%BC%8CURI%EF%BC%8CHTML%EF%BC%8C%E3%81%9D%E3%81%97%E3%81%A6REST-WEB-PRESS-plus-ebook/dp/B07JK7FZH2)に軽く目を通したので、印象に残った点などをまとめていきます。

# ハイパーメディア
ハイパーメディアとはテキストや画像・音声などの様々なメディアをハイパーリンクによって，結びつけることにより構成するシステムのこと。本や映画といった始まりから終わりにかけて情報を伝えるメディアとは対照的に非線形な情報を伝える。

#RESTとは
Representational State Transfer の略でWebのアーキテクチャスタイルのこと。
HTTP(Hypertext Transfer Protocol)はテキスト以外に画像や音声などの情報を運んでおり、それらを「リソースの状態」(Resource State)の「表現」(Representation)とする考えから名づけられている。ここでいうリソースとは、「Web上にある、名前を持った情報」のこと。（文書や画像など）
ここでいうリソースの名前とはURI()のことである。
RESTは複合アーキテクチャであり、下記6つのアーキテクチャスタイルを組み合わせたものである。

- クライアント/サーバ
- ステートレスサーバ
- キャッシュ
- 統一インタフェース
- 階層化システム
- コードオンデマンド

#ステートレス
ステートレスとはサーバ側でクライアントの状態を管理しない制約のこと。
人間の会話でいうところの「文脈」的なものをサーバ側が持たないため、クライアントは必要な情報を全てリクエストに含めて転送しなければ、欲しいレスポンスを得ることはできない。そのため、ステートフル（ステートレスの反対）に比べ、送信する情報量が多くなるというデメリットがある。
一方で、サーバ側でクライアントの状態を管理しないことから、サーバ側のシステムが単純になることや、リクエストの送信先がどのサーバでも構わないといった利点がある。

例えば、100台のクライアントを処理できるサーバA,サーバBがあったとする。
クライアントAが1回目のリクエストをサーバAに送った場合、ステートフル下では2回目以降のリクエストもサーバAに対して、送らないと欲しい結果を得ることができない。クライアントAとの文脈を保持しているのは、サーバAのみであり、サーバBは文脈を保持していないからだ。
一方でステートレス下ではリクエストに必要な情報がすべて詰められているので、リクエストの向き先がどちらのサーバであっても欲しい結果を得ることができる。

#URI
Uniform Resource Identifierの略。
決められたルールに基づいてつけられた，リソースを一意に特定するための識別子。URIを使うことでWeb上のすべてのリソースを一意に示すことができる。

##URIには良し悪しがある
良いURIは「クールURI」と呼ばれ，変わらない（変わりにくいこと）が良いURIの条件である。  
なぜなら，webはハイパーメディアであり，URI（リンク）が変わることにより，リンク切れが多発してしまうとwebが機能しなくたってしまうから。

#HTTPメソッド
HTTPメソッドは8種類のみであり、そのうち主に使われているのは6種類。
GET,POST,PUT,DELETEはCRUDの性質をもち、使用頻度が高い。

|メソッド名| 意味 | CRUD性質|
|  ---  |---                      |---|
|  GET  |  リソースの取得                       | Read(取得）|
|  POST |  リソースの作成，その他の処理        |  Create(作成）|
|  PUT  |  リソースの更新，リソースの作成          | Update(更新)|
|DELETE |  リソースの削除          | Delete(削除）|
|HEAD   | リソースのヘッダの取得(ボディ部は返ってこない）   |  -  |
|OPTIONS|  リソースがサポートしているメソッド | - | 

※他にTRACE,CONNECTがある。

## リソース作成時はPOST or PUT?
リソースのURIの決定権がサーバ側にある場合はPOSTを，クライアント側でURIを決定できる場合はPUTを使う。

``` sh
PUT  /api/wiki/ハイパーメディア
POST /api/users
```

##冪等性と安全性
冪等とは[「同じ操作を何度繰り返しても、同じ結果が得られる性質」のこと](https://qiita.com/suin/items/316cb8aaf8dfcf11abae#restful%E3%81%AB%E3%81%8A%E3%81%91%E3%82%8B%E5%86%AA%E7%AD%89%E6%80%A7)
安全性とは「リソースの状態を変化させない性質」のこと。

|メソッド名| 冪等性 | 安全性|
|  ---  |---         |---  |
|  GET  |  あり      | あり|
|  POST |  なし      | なし|
|  PUT  |  あり      | なし|
|DELETE |  あり      | なし|

したがって、WebAPIを設計する際には、上記の冪等性や安全性を考慮したうえで設計する必要がある。
例えば、GETメソッドでリソースの更新や削除を行うのは誤った使い方であり、GETメソッドの冪等性や安全性が失われてしまう。


#ステータスコード
ステータスコードはステータスライン（レスポンスの1行目）に含まれる3桁の数字のことで、レスポンスの内容を示す。
先頭の数字(1~5）で大別され、下記の意味を示す。

- 1〇〇：情報
    - 処理が継続中であったり、追加情報の要求を示す。
- 2〇〇：成功
    - リクエストが成功したことを示す。
- 3〇〇：リダイレクト
    - 別リソースへのリダイレクトを示す。クライアントは指示された別リソースへリダイレクトする。
- 4〇〇：クライアントエラー
    - クライアント側のエラーを示す。リクエストに問題がある。
- 5〇〇：サーバエラー
    - サーバ側のエラーを示す。

##よく見るステータスコード
|コード | 意味|
|---| --- | 
|200:OK | リクエスト成功 |
|201:Created | リソースの作成完了|
|301:Moved Permanently |リソースの移動 |
|303:See Other |他のURIの参照 |
|400:Bad Request |リクエスト不正 |
|401:Unauthorized |アクセス権がない |
|404:Not Found |リソース不在 |
|500:Internal Server Error |サーバ内部エラー |
|503:Service Unavailable  | サービス利用不可 | 


#おわり
読んだ本について投稿するのは初めてでしたが、自分なりに整理できるので良い機会になりました。
これから技術書を読むときは先に知りたい情報決めて、qiitaの目次だけ作ってから読むのもありかもとか思ったりしました。