RESTとGraphQLについて
1. RESTとGraphQLについて
1.1. API について
- 概要
読み方
- API (
Application Programming Interface
) と呼ぶ。
※アプリケーションプログラミングインタフェース
- API (
どういったものか
-
ソフトウェアコンポーネント ( 部品 ) 同士が互いに情報をやり取りするために使用する
為にデータや手順などを定めた規約のことを指す。 -
例
個々の開発者などが毎回全ての機能を一から開発するのは無駄で困難なため OS やミドルウェア
などの形で提供されプログラミング言語で言うところのライブラリ ( 汎用的な関数群 ) が
まとめて提供され利用者は使いたい機能を呼び出すことで容易にやりたいことが実現できる
インターフェース (やり口
) を提供してくれるもののこと。
マウス、キーボード、 USB など特に意識しなくても繋げば使える状態になるこれは
インターフェースで規約として定義されているから。
-
ソフトウェアコンポーネント ( 部品 ) 同士が互いに情報をやり取りするために使用する
1.2. RESTful API について
-
概要
読み方
- REST (
Representational State Transfer
) と呼ぶ。
※リペゼンショナルステートトランスファー
- REST (
どういったものか
- WebAPI の設計モデルでパラメータを指定して HTTP メソッド (
get
,post
,put
,delete
)
でアクセスを行うことでデータの送受信 (xml
やjson
) システムの事を指す。
WEB システムとデータのリソースの取得, リソースの登録, 更新, 削除ができるため
スマートフォンなどのアプリケーションのデータ表示などに使われている。
リクエスト例 : https://example.com/api/v4/channels/nb1d3a7yhtfnznp4uno8jehmbo/posts?page=0&per_page=30
- WebAPI の設計モデルでパラメータを指定して HTTP メソッド (
-
特徴
利点
- モバイルアプリケーションへの対応が容易になる。
いつでもどこからでも情報にアクセスできるのが最大の特徴ですがデータ量が大きかったり
すると待機時間が長くなることで不具合を起こすことがありますが, REST の場合は必ず
JSON や XML といった形で返却されるためシステムとの連携が容易になる。
- モバイルアプリケーションへの対応が容易になる。
欠点
- 設計の自由度が高い反面, 実装ルールの統一性がない
-
基本的に RESTful API は, REST の原則に沿っていれば記述自体は
自由度の高い API と言えるが, 実装ルールに統一性がないため充分に理解
しないまま作られた, RESTful API が作られてしまう。 -
REST の原則
- アドレス指定可能なURIで公開されていること
- インターフェース( HTTPメソッドの利用 ) の統一がされていること
-
ステートレスであること
- サーバーはクライアントのセッション情報を保持しないことを指す。
- 処理結果が HTTP ステータスコードで通知されること
-
基本的に RESTful API は, REST の原則に沿っていれば記述自体は
- 設計の自由度が高い反面, 実装ルールの統一性がない
1.3. GraphQL について
-
概要
読み方
GraphQL- QL ( query and manipulation language )
※推測
※クエリアンドマニュプレーションラングエッジ
※または単にグラフィクルもしくはグラフキューエル
と呼ぶこともある。データクエリとデータ操作のための言語という意味。
- QL ( query and manipulation language )
どういったものか
- GraphQL は Facebook によって開発されたオープンソースのクエリ言語
で問い合わせを行う為の言語となりクライアントとサーバ間のデータのやり取り
を容易に記述するために作られた言語。
- GraphQL は Facebook によって開発されたオープンソースのクエリ言語
-
特徴
利点
- エンドポイント ( 末端 ) が一つだけ存在する。
- RESTful API はリクエスト先を独自に決められ複数のリソースへの
アクセス時にそれぞれのリクエスト先が複数存在することになるので
管理が複雑になる反面, GraphQL では問い合わせ先が単一で必要な
データのみリクエストし受け取ることができる。
- RESTful API はリクエスト先を独自に決められ複数のリソースへの
- エンドポイント ( 末端 ) が一つだけ存在する。
欠点
-
パフォーマンスの分析がやりにくい
- エンドポイントは必ず 1 つなので REST のように複数のエンドポイント
ごとでの記録や分析ができない面がある。
- エンドポイントは必ず 1 つなので REST のように複数のエンドポイント
-
画像なのどバイナリデータの扱いがしにくい
- ほとんどのデータを JSON やり取りするのでデータサイズが大きく
なってしまう欠点がある。
- ほとんどのデータを JSON やり取りするのでデータサイズが大きく
-
パフォーマンスの分析がやりにくい
ディスカッション
コメント一覧
まだ、コメントがありません