REST?
-
WWW見たいな分散ハイパーメディアシステムーを作るソフトウェアアーキテクチャスタイルの一つ
-
ソフトウェアアーキテクチャ？
システムーを構成する要素(サブシステムー、コンポーネント)とその関係を表現する仕組み
ウェブの既存技術とHTTPプロトコルを利用することに意味があり、ウェブの長所を最大活用
-
-
ネットワーク上クライアントとサーバー間の通信方法の一つ
-
REST (Representational State Transfer)
→ 資源をユニークーな名前で区別(資源の表現)し、その表現の状態をやり取りすること
-
資源(Resource)
ソフトウェアが管理できる全てのこと
e.g., 文書、イメージ、テキスト、ソフトウェアなど..
-
資源の表現(Representation)
資源を区別する名前
e.g.,
[資源] 色んな生徒情報 → [表現] 'student'
[資源] 色んな食べ物情報 → [表現] 'food'
-
状態(情報) 伝達
リクエスト時点で該当資源の状態(情報)を伝える
JSONおよびXML形式のデータをやり取りすることが一般的だ
-
RESTの具体的概念
-
RESTはHTTPのURI形式で資源を表現
-
HTTPメソッド(GET, POST, PUT, DELETE)で該当資源に対するCRUD作業をする
→ RESTは資源指向アーキテクチャ(ROA, Resources Oriented Architecture)
メリット
- HTTPの技術とインフラをそのまま使う → REST APIのために別のインフラを構築する必要ない
- HTTPを使う全プラットフォームで使用可能
- HTTPにあるハイパーメディア汎用性
- REST API 表現がクリアーになる → 意味を分かりやすい
- サービスデザインに発生できる問題の最小化 (HTTPで一貫性を保つから)
- サーバーとクライアントの役割を明確に分ける
デメリット
- 決められた(REST)標準がない
- メソッド限界(CRUD形式の限界)
- 古いブラウザー問題
- PUT, DELETE サポート X
- pushState サポート X
RESTが必要な理由
-
アプリケーション(サービス)の分離や合わせることがやすい(レゴブロックのように簡単にできる)
-
ブラウザーだけではなくって様々なクライアント種類の使いができる
(HTTPだけ使えればどのデバイスでも可能)⇒ つまり、RESTはマルチープラットフォームのサポートするサービス(資源)アーキテクチャとして適切
構成要素
-
資源(Resource)
サーバーにある、HTTP URIで表現できる全データ
ユニークなIDが存在
e.g., /students/:student_id
クライアントはURIを使って特定資源の状態(情報)に対する操作をリクエスト
-
行為(Verb)
HTTPメソッド → GET, POST, PUT, DELETE ...
-
表現(Representation)
JSONやXML見たいに色んな種類の形式で表す
JSONやXMLが一般的
特徴
クライアントとサーバーの関係
-
クライアント
資源を要請するサイド
ユーザー認証、Context(脈絡：セッション、ログインしたユーザーの情報)を管理
-
サーバー
資源を持つサイド
資源を操作するAPIを提供
ビジネスロジック処理とデータのセーブを担当
Stateless
-
RESTはHTTPのStateless特徴をそのまま保つ
-
サーバーは様々の要請を独立した別のものとして扱う(リクエスト間の関係があるといけない)
⇒ サーバーの処理方法に一貫性ができて、サーバーが単純になりサービスがもっと自由になる
Cacheable
-
RESTはHTTPのキャッシング特徴をそのまま使う
→ Last-Modified タッグなどを利用するキャッシング可能
-
キャッシングはトランザクションの節約を使って、
基本的な応答時間が速くなって全体的にサーバーの性能を改善させる
Layered System
-
REST API サーバーを多数の階層で構成できる
-
ビジネスロジックのためREST APIサーバー前にセキュリティー、ロードバランシング、認証、暗号化などの機能を階層で追加
⇒ サーバーの柔軟性を高める
-
-
Proxy、ゲートウェイと同じ媒体を使える
Code-On-Demand
- 絶対的にする必要はない特徴
- サーバーからもらうスクリプトをクライアントで実行すること
Uniform Interface
-
URIで指定された資源に対する操作がHTTPによって統一する
→HTTPを従うどのプラットフォームでも使える
⇒ マルチプラットフォームサポート可能
RESTful
- あるウェブサービスがRESTアーキテクチャを十分適用していることを表す言葉
RESTfulじゃない場合
-
CRUD機能を全部POSTでやってしまうAPI
-
URIに資源、id以外の情報を入れた場合
e.g., /users/items/addItem
REST API
-
API?
Application Programming Interface
→ オーエス、言語またどのサービスが自分の機能操作のため外部に提供するインタフェース
-
RESTful API
RESTを基盤で作るサービスAPI
REST API 特徴
-
REST基盤でシステムを分散させる → サービス拡張性、再活用性の増加でメインテナンスと運用が便利になる
-
HTTPが使えるプログラミング言語なら簡単にクライアントーサーバーを作る
REST API 設計基本ルール
ドキュメント: クラスのインスタンス、データベースのレコードと類似した概念；個体を表す
コレクション: サーバーで管理するディレクトリー(資源)
ストア: クライアントで管理する資源レポジトリ
-
URIは資源を表す
- 動詞より名詞、大文字より小文字を使う
- ドキュメント名は単数名詞を使う
- コレクション名は複数名詞を使う
- ストア名は複数名詞を使う
-
資源に対する行為はHTTPメソッドで表す
-
URIにHTTPメソッドを入れない
e.g., [GET] /students/delete/1 ⇒ [DELETE] /students/1
-
URIに行為を表す動詞を入れない
e.g., [GET] /members/show/1 ⇒ [GET] /members/1
-
URI中で、変わるものはユニークバリューに変える (id見たいなユニークバリュー)
e.g., [DELETE] /cars/23, [GET] /cars/17
-
REST API 設計ルール
-
スラッシュ(/)は階層構造のため使える
e.g., /animals/dogs/bulldogs
-
スラッシュ(/)は最後の文字に使えない
-
ハイフン(-)は可読性増加のため使える
-
アンダーバー(_)は使えない
-
小文字を使う
-
ファイル拡張子は含まれない
-
資源同士の関係がある場合
/資源1/資源 id/資源2
e.g., [GET] /users/{user_id}/items
