（＊）この記事では自分が理解した（できた）ことだけを書いて行きます。
今回見た動画は
######When to use GraphQL over REST?
主にバックエンドについて情報発信しているバーレーン人Hussein Nasserという方の動画。
動画の構成
今回はRESTとの比較から、GraphQLの利点や使用例、逆にRESTの方が好ましい場合について解説しています。
各項目にそって比較や考察を行います。
RESTとの比較
下の表は動画で紹介されている比較表を日本語訳したものです。
×マークは使用不可ではなく、好ましくないの意。
| 使用例 | GraphQL | REST |
|---|---|---|
| 使用方法の予測できない公開API | ○ | × |
| 特定の使用目的のために作られたAPI | × | ○ |
| 一つのクライアントに対応 | × | ○ |
| 企業API | ○ | × |
| よく定義されたスキーマ | ○ | × |
| 上から順に進めます。 |
1.使用方法の不明な公開API
RESTは構築の際にクライアント側の要求を出来る限り満たさなければなりません。クライアント側では要件を満たすために複数回バックエンド側にアクセスする可能性があります。全ての要件を満たすRESTのスケーリングは複雑で困難です。
2.特定の使用目的のために作られたAPI
使用目的が限られていて、どのようなクエリが送られて来るのか知っているのであれば、RESTが好ましいです。キャッシングの恩恵が受けられ、RESTのシンプルさを活用できます。
3.一つのクライアントに対応
ウェブページやモバイルアプリなど、クライアントが一つに絞られるなら、RESTの方が時間の節約になります。
4.企業API
GraphQLの良い使用例はニューヨークタイムズです。GraphQLなら一つのインターフェースで他の団体や他の分野での利用に対応できます。
5.よく定義されたスキーマ
GraphQLはよく定義されたスキーマとの相性がいいですが、データベースのスキーマをクライアント側に曝してしまうため、攻撃者が意図的に負荷をかけてサーバーをダウンさせる可能性があります。
#まとめ
用途やクライアントが限定されるならREST、クライアント側の多様な要件に応じて、無駄なく柔軟に対応したいのであればGraphQL。
今回が初投稿となります。ご助言いただければ幸いです。
補足(2020/4/23)
(よく定義されたスキーマ＝well defined schemaの意味が自分ではよく分からなかったのですが、wikipediaによれば、well-definedは，数学用語で 「定義によって一意の解釈又は値が割り当てられる」の意だそうです。well-defined functionと言う場合には引数に対してuniqueな値を返す関数のことを指すようです。)
参考
https://math.stackexchange.com/questions/606917/well-defined-function-what-does-it-mean