API の開発とかを手掛けていて、REST？ステートフルとステートレスってなんだ？
…となったので調べてみました。
ステートフルとステートレスについて
ステートフル（stateful）とステートレス（stateless）については結論からいうと、状態を維持する仕組みをステートフル、状態を維持しない仕組みをステートレスと呼ぶそうです。
クライアントとサーバー間のやりとりにはステートフルとステートレスという仕組みがあり、このやりとりを維持するかしないかが違いになります。
| ステートフル（stateful） | 前回のデータを保存して、データ保存した内容を処理結果に反映される仕組み |
| ステートレス（stateless） | 前回のデータを保存しないで、前回のデータを内容に処理結果に反映させない仕組み |
ステートとは、ある特定の時点のアプリケーション (実際には、それに限られないさまざまなもの) の調子や品質、つまり、その状態のことです。あるものがステートフルかステートレスかは、別の何かとの通信の状態が記録される期間と、その情報をどのように保存する必要があるかによって決まるとのことでした。
メリット
ステートフル（stateful）
- やり取りが完結に済む
- それによりネットワークの帯域を節約できる
ステートレス（stateless）
- クライアントのリクエストは状態に依存せず、常にリソースに対する操作に必要十分な情報となる
- サーバが増えてもそのままのリクエストでいつも同じリソースに対する操作ができる
- スケールアウトに向いている
- 処理がクライアントの状態に依らないので処理がシンプル
デメリット
ステートフル（stateful）
- クライアントの状態を都度把握しておかなければいけないのでクライアントが増えると負荷も増える
- サーバを複数台設置する場合にはそれぞれのサーバ間でクライアントの状態を同期しなければいけない
- スケールアウトには向かない
ステートレス（stateless）
- やり取りが冗長になりがちである
- リソースへの操作が必要になる度にそのやり取りを繰り返す必要がある
- サーバが状態を保持していないのでトラブル時のハンドリングが難しい場合がある
REST について
REpresentational State Transferの略で4つの設計原則があるようです。
- セッションなどの状態管理を行わない。(ステートレス)
- 情報の操作(取得、作成、更新、削除)は全てHTTPメソッド(GET、POST、PUT、DELETE)を利用する。
- すべての情報は汎用的な構文で一意に識別される。（URLやURIなど）
- 情報の内部に、別の情報や(その情報の別の)状態へのリンクを含めることができる。
REST ではないアプリケーションの例
| 処理内容 | URL | HTTPメソッド |
|---|---|---|
| レコード作成 | /create | POST |
| レコード取得 | /record/1234 | GET |
| レコード削除 | /delete_record/1234 | GET |
| レコード編集 | /edit_record/1234 | GET |
REST なアプリケーションの例
| 処理内容 | URL | HTTPメソッド |
|---|---|---|
| レコード作成 | /record | POST |
| レコード取得 | /record/1234 | GET |
| レコード削除 | /record/1234 | DELETE |
| レコード編集 | /record/1234 | PUT |
