RESTって何？

投稿者 投稿日:

RESTという言葉が世の中に広まった昨今
理解を深めようとRESTについて改めて自分なりに整理してみました

RESTとは

REpresentational State Transfer の略。

Representational

意味は「具象的な」→ 具象的とは「直接それとわかるようなはっきりした形をもっているさま。」
反対語として「抽象的」abstract

State

意味「状態、ありさま」など

Transfer

意味「運ぶ、転送」など

それぞれの単語でみてもいまいちピンときません…
というのも、Transferとかついているけど結局RESTってやつが実際に
何かしらで存在していてデータを送信してくれるか　というとそうではなく
ソフトウェア同士がデータをやり取りする上での設計の考え方や条件だよ　ということです

RESTfulとは

前述のRESTの「考え方、条件」に則って、HTTP通信のやり取りを行う「インターフェース」のこと

RESTful API（REST API）とはそういった「インターフェース」で作成されたWebAPI

RESTful APIだとか、REST APIだとかはどちらも広義では同じ意味で
RESTに考え方に忠実に則っているのがRESTful、体制や組織にあわせて
カスタマイズしているのがRESTといったところでしょうか
ここではREST、REST APIで統一します


ただ述べられる上ではどちらもRESTを意識してはいるので同じ目的で
作られたものだということです

RESTの「考え方、条件」とは

考え方、条件とはつまりは「RESTに則る、つまりRESTの原則に合わせましょう」ということです

ではその原則はというと、4つの原則があります

ステートレス

HTTPリクエストの際に、情報がすべてHTTPメッセージ内に含まれており
セッションなどの状態管理を持っていないことを指します

統一されたインターフェース

情報の操作をすべてHTTPメソッド（GET、POST、PUT、DELETEなど）を
使って操作すること

リソースが一意にわかるアドレス

データがURI（Uniform Resource Identifier）で特定でき、
すべてのデータがこのURIを持っている

他の情報へのリンクが持てる

別のデータリソースへのリンクを含めることができる

とざっと上げてみましたが、これまたピンとこないところもある
のでわからない部分を個別にまとめてみます

ステートレス、ステートフルの違い

ステートフル

サーバー側がクライアントのセッション状態を保持している
つまりサーバ側で情報を持つ必要があるため、サーバ側のリソース圧迫やレスポンス遅延にもつながってしまう（デメリット）
ただ、1回の通信内の情報は少なくて済む（メリット）

ステートレス

サーバ側はクライアントのセッション情報を持たない
サーバとクライアントのやり取りは小さな情報でやり取りするため、
サーバ側のリソース圧迫やレスポンス遅延が発生しづらい、処理も単純化できる（メリット）
対話形式のように情報を徐々に増やしいくようなやり取りでは通信内の情報が冗長になる（デメリット）

理解を深めるために身近な日常のシーンで問題を用意してみました

問題①お店での以下の注文はステートフルでしょうか、ステートレスでしょうか

※店員(サーバ)、客(クライアント)と置き換えて考えてください

やり取り

店員:いらっしゃいませ。店内でお召し上がりですが、お持ち帰りですか
客:店内

店員:ご注文は何になさいますか
客:ビッグマックセット

店員:サイドメニューは何になさいますか
客:ポテト

店員:ドリンクは何になさいますか
客:コーラ

店員:以上でよろしいですか
客:はい

店員:かしこまりました(^o-)ミ★ (スマイル無料)

答え ステートフル

問題②お店での以下の注文はステートフルでしょうか、ステートレスでしょうか

やり取り

店員:いらっしゃいませ。店内でお召し上がりですが、お持ち帰りですか
客:店内

店員:ご注文は何になさいますか
客:店内で、ビッグマックセット

店員:サイドメニューは何になさいますか
客:店内で、ビッグマックセットのポテト

店員:ドリンクは何になさいますか
客:店内で、ビッグマックセットのポテトとコーラ

店員:以上でよろしいですか
客:店内で、ビッグマックセットのポテトとコーラ、以上

店員:かしこまりました(^o-)ミ★ (スマイル無料)

答え ステートレス

URI、URL、URNの違い

簡単に言うとURI = URL + URN
大体のイメージは URI = URL

じゃあ、URLとは?
https://kusumo-t.com/user/1234
このように、サーバー内でファイルがどこにあるかの位置を示す文字列

じゃあ、URNとは?
これはどの位置にファイルがあってもURI文字列が変わらない形式です
インターネット上のファイルにIDを与え、そのIDを使用し て URI 文字列を作ります

自分たちの日常に当てはめると

  • URI = 宛先
  • URL = 住所
  • URN = 名前

郵便に記載されている情報がまさにURI、URL、URNで表現されていて
わかりやすいと思います

REST的に考えるURLとは？

https://kusumo-t.com/api/users/getuserinfo
https://kusumo-t.com/api/users/newuserinfo
https://kusumo-t.com/api/users/updateuser
https://kusumo-t.com/api/users/deleteuser
https://kusumo-t.com/api/users

user(リソース)を扱うURLを1つ(一意となるものを)用意する

RESTとHTTPメソッドの考え方

HTTPメソッドの種類(以下HTTP1.1バージョン)

メソッド説明・用途
GETURIに指定したリソースの転送を行い、サーバからリクエストを送ったリ ソースのデータを受け取る
HEADGETと似ているが、レスポンスヘッダだけを要求して、レスポンスボディは 取得しない。GETの前にどのようなリソースが返ってくるのかを調べるのに使う
POSTクライアントからサーバにデータを送信し、リソースを作成する。フォームなどでデータを送信するときに使う
PUTリソースを更新する。またリソースの作成もできるがPOSTに任せた方が良さげ
DELETEリソースを削除する
OPTIONSリソースで使用できるリクエストメソッドの取得。通信オプションを通知したり調べるときに使う
TRACEリクエストをそのまま返却する。サーバ側で受け取ったリクエストラインとヘッダーをそのままクライアントに送り返す。
プロキシサーバなどを使う環境で、リクエストが書き換えられる様子を調べるときに使う
CONNECTリソースで指定されたサーバにトンネルを確立する。暗号化したメッセージ をプロキシで転送する際に使う
PATCHリソースを部分的に変更するために使う

REST APIでのCRUDとの対応表

HTTPメソッドCRUD操作
GETREAD
POSTCREATE
PUT / PATCHUPDATE
DELETEDELETE

HTTPメソッドの使い分け

HTTPメソッド性質利用する場面
GET冪等 and 安全リソース取得
POSTNOT 冪等 and NOT 安全リソース作成
PUT冪等 and NOT 安全リソース更新（すべて）
DELETE冪等 and NOT 安全リソース削除
PATCHNOT 冪等 and NOT 安全 リソース更新（部分的）

※冪等（べきとう）とは「ある操作を何回行っても結果が同じこと」を意味する数学的用語です

GET / POSTのみのformでどうするのか

GET/POST以外のメソッドをサーバ側が受け取りたい・・・けど
formタグではそれ以外入れても
例えば以下のようにmethodにdeleteを入れても失敗します
アクセスログの部分をみてみると、GETのままになっています

<form method="delete" action="/">
    <input type="text" name="textArea">
    <input type="submit" value="削除">
</form>

以下はアクセスログより
192.168.33.1 - - [10/Jul/2020:08:00:00 +0900] "GET /?textArea= HTTP/1.1" 200 198 0.0008

なので、以下のようにするとメソッドを変更できる
formのmethodはPOSTを利用し、
hidden項目で _methodとしてDELETEをセットする
こうすることでアクセスログを見てみるとDELETEになっていることがわかる

<form method="post" action="/">
    <input type="text" name="textArea">
    <input type="hidden" name="_method" value="DELETE">
    <input type="submit" value="削除">
</form>

以下はアクセスログより
192.168.33.1 - - [10/Jul/2020:08:00:00 +0900] "DELETE / HTTP/1.1" 200 212 0.0014

REST の URLは結局どんなイメージなのか

ユーザというリソースを操作するケースで考えてみます

処理内容HTTPメソッド + URL
ユーザ情報を複数取得するGET /users
ユーザ情報を1つ取得するGET /users/{ユーザID}
ユーザ情報を追加するPOST /users
ユーザ情報を更新するPUT /users/{ユーザID}
ユーザ情報を削除するDELETE /users/{ユーザID}

まとめ

改めて自分なりにまとめてみました
HTTPメソッドも普段使う以外に実は他にも色々あったり
URI、URL、URNの違いとか、冪等（べきとう）の性質とか
振り返って学びになることも多くありますね

関連記事

  1. Laravel(6.x) 複数のデータベース（DB）に接続する
  2. Laravel(6.x)のAuthを使ってログイン機能を作る
  3. 【Webp】準備編 Homebrew PHP7.3インストール〜gd確認まで
  4. Laravel(6.x) assetファイルにタイムスタンプを使わずmix versionを使う