そもそもGraph QLとREST APIって？？
webから情報を取ってくるためのアーキテクチャ。
それぞれ考え方が違う
REST API
今までの一般的な考え方。
RESTはRepresentational State Transferの略で、HTTPを使ってアクセスすることでデータの送受信をする
決まったURIにリクエストを飛ばすと、決まったデータが返ってくるような考え方で、GET, PUT, POST, DELETEを指定する。
RESTful
REST APIの設計原則。
-
ステートレス性
- サーバー側にユーザーのセッション情報を保持しない→ 拡張性に優れる
https://yohei-y.blogspot.com/2007/10/blog-post.html が分かりやすかった
-
リソースの識別
- それぞれのページや画像は一意なURLを持っていて、そこにアクセスすることで情報を取ってこれる
-
統一インターフェース
- 情報の操作はすべてhttpメソッド(get, put, post, delete)を使うこと
- httpメソッドでpostしてjsonで帰ってくるみたいな感じで、あらかじめ、定義・共有された方法でやり取りされる
-
接続性
- APIのレスポンスがリンクを含めるべきであるという考え方。リンクをレスポンスに含めることで、次にアクセスすべきページが分かりやすくなる
-
キャッシュ可能
- データが変わらない限り、キャッシュされた情報を利用することができるので、負荷軽減できる
Graph QL
APIのクエリ言語。
誤解を恐れずに言うとSQLのクエリをフロントエンドから叩くイメージ
メリット
- 指定したデータのみ取得するので、余計なデータを取得せずに済む
- ネットの帯域を圧迫せず、パフォーマンス向上が見込まれる
- エンドポイントを何個も作る必要が無く、1つだけでいい。
- 型指定をするのでデータが明確になる
デメリット
- リクエストが柔軟なので、セキュリティ上の注意が必要。
- レスポンスに含める要素をユーザーが指定してしまうので、キャッシュしにくい
- バックエンド側の処理が複雑になり、レスポンスにかかる時間が長くなりがち