【技術】REST API,GraphQL,gRPC
REST API(REpresentational State Transfer API)、GraphQL、gRPC(g Remote Procedure Call)これらの名前を聞いたことがあるだろうか？
自分はよくわかっていないので整理していこうと思う。
これらは何？
これらはすべてWEB APIというものにカテゴライズされるIT用語である。
まず、WEB APIが何かから整理していく。
WEB API？
API(Application Programming Interface)とはアプリケーションやソフトウェア同士をつなぐ機能を指す。
そのつなぐ機能をWEB(インターネット)を介して行うアプリケーションやプログラムをWEB APIと呼ぶ。
APIを利用するとは、ソフトウェアにAPIという外部とやり取りする窓口を作り、他のアプリケーションやソフトウェアとやりとりできる状態にすることを指す。
イメージが沸く説明をしている記事を見つけたので下記に引用する。
鎖国時代の日本と諸外国は連携することが困難でしたが、諸外国との貿易を許されていた唯一の場所である長崎の出島をうまく活用することで、日本との貿易や文化交流、情報交換が行えるようになった、という歴史の話がありますが、日本を一つのソフトウェア、諸外国をまた別のソフトウェアと考えると、出島が司っていたのが言ってみればその二つを繋げるAPI機能です。
WEB APIの何がうれしいの？
なんとなくWEB APIのイメージが持てたであろうところで、WEB APIが存在して何がうれしいのか、利用側、提供側それぞれのメリットをいくつか挙げてみたい。
利用者としては、APIを用いてほかのアプリケーションを利用することで開発の効率化が図れることが挙げられる。
アプリを作る際にログイン機能や例えば天気の情報や地図の情報を提供しているAPIを利用すれば、そこを作る工数を削減することができる。またログイン等セキュリティに関係する箇所でバグを起こしたら重大な障害になる部分を信頼と実績のある外部サービスを利用することでリスク回避可能になる。
提供者としてのメリットは、APIを利用してもらうことにより課金できることの他にAPIとしてほかのサービスに組み込んでもらうことによって、自社サービスではリーチできなかった層に使ってもらえ、使い勝手などを見てもらえることなどがあげられる。
なぜ、こんなにたくさん通信規格があるのか？
異なるマシン上で動作するサービス間で情報をやり取りするAPI、手法にはさまざまなものがあるがなぜたくさんあるのか？一言でいうなら、時代によって求めるものが変わったり、使い方によって改良版が生み出されたりするからである。
上記に挙げた３つのWEB APIを誕生した時代と作成者で整理してみる
このほかにもSOAP APIがあったり等様々なAPIが産まれてきた。
それぞれの時代に必要と考えられた仕組みとして誕生し消えていっている。
それぞれの特徴は？
まず、断っておきたいのがREST APIが作られた時代とそれ以外のAPIが作られた時代はかなり違う。なのでREST APIの時代から技術が進歩したことやREST APIのデメリットをカバーする形で２つのAPIは出てきている。
・REST API
特徴は以下の４つである。インターネット上の情報をリソースととらえ、そのリソースにアクセスするためのルールをまとめるというリソース指向アーキテクチャなのもREST APIの特徴である。
①アドレス可用性：
REST APIとして使えるものはURIを通して表現できる。URIのパスで一意に役割が決まる。
②ステートレス性：
HTTPをベースにしたステートレスなクライアント/サーバ間の通信をする。双方向の通信などでもなく、こちらからのリクエストのたびに完結する形でリスポンスをもらう通信である。
③接続性：
情報の内部に、別の情報や状態へのリンクを含めることができる。（すみません、この意味が自分でも腹落ちしていないのでわかるようになったら更新します。。。）
④統一インターフェース：
リソースの操作（取得、作成、更新、削除）はすべてHTTPメソッド（GET,POST,PUT,DELETE）を利用される。
このメリットを利用して利用者が伸びたのがAmazonだったりTwitterであった。Twitterに関してはbotが沢山生まれたり、Twitterを使いやすいようなブラウザが作られたりといろいろな利用用途が産まれた。
ただ、デメリットもいくつかある。①で上げたアドレスの可用性であるが、特定のアドレスを利用して得たリソースは利用者の意図した情報に対して過剰/過少であることが多様にして発生し、オーバーフェッチしてしまうことによるメモリへの負荷など発生している。
またマイクロサービスの台頭などによりWEB APIを組み合わせてのサービス作成が増えるにつれてこうしたAPIのレスポンスの悪さやメモリへの負荷はデメリットとして目立つようになってきた。そこで下記のWEB APIである。
・GraphQL
Facebookにより作成されたWEB API。
作成される前の2012年ごろREST APIでいろいろサービスを開発していたところRESTAPIの課題である過大/過小なデータ取得の影響を受け、アプリのクラッシュが頻発していた。
この問題を解決するためにグラフ理論をもとにGraphQLを開発
特徴としては以下の３つが挙げられる
①柔軟なクエリ：
３種類の柔軟なクエリにより、過大/過小なデータ取得を防ぐ。
・データ取得時に引数を渡すことにより取得したいデータを限定する。
・指定したデータのみの変更(POST/UPDATE/DELETE)
・subscription:変更管理:websocket(TCP上で低コストで双方向通信ができる仕組み)により通信を行い、サーバ側のデータ変更をクライアント側が検知
②エンドポイントの統一：
REST APIではAPIの通信先リソースごとにURIを持っていたのに対し、GraphQLではGraphQLクライアントから見たエンドポイントはGraphQLサーバのみとなる。こうすることにクライアント側でプログラムを作成する際にエンドポイントごとにURIを入れ込む必要がなくなる。
③型とスキーマ：
GraphQLを利用する際には、利用しているフレームワークや言語に依存せずリクエストを投げることができる。それを可能にしているのがスキーマ定義言語（SDL(Schema Definition Language)）である。
取得したい情報の型を指定するためのルールブックのようなものをSDLで作成すれば利用しているプラットフォームによらず実行が可能である。
GraphQLを見るとREST APIのデメリットである、データ取得時の過大/過小な取得によるオーバーヘッドを解消しようとしていることが理解できる。
ただ、大きなデメリットとして、GraphQLはREST APIを内部でラップしており、HTTPメソッドによるエラーハンドリングができない（すべてステータス200で返ってくる）
・gRPC
最後にgRPCについて、
RESTが別アプリケーションの「リソース」の取得・操作を目的にしているのに対し、あくまでもRPC(Remote Procedue Call)の目的は「リモートメソッドのコール」を基準にしている。遠く離れたサーバにあるメソッドをまるで隣にいるように実行することを目的としています。
マイクロサービスのようにAPIを高いパフォーマンスで実行するサーバ間通信のプロトコルを目指す。
gRPCの特徴は以下の３つである。
①Protocol Buffersによる実装：
Googleが2008年にオープンソース化したシリアライズフォーマット。
IDL(インターフェース記述言語)を用いて、任意の言語のサーバ/クライアント用のコードを生成。このIDL,多言語に対応しており、異言語間のやり取りが発生しうるマイクロサービスの開発と相性が良い。
②HTTP/2による高速な通信：
HTTP/２はHTTP/1の問題点を解消する形で誕生した。
調べる限りHTTP/2と/1を区別する大きな違いは双方向通信においてである。
HTTP/1ではステートフルな通信を想定していなかったことによるところが多いが、HTTP/1では双方向通信をするためにはポーリングやKeep-Aliveなどのロングポーリング等があるが、頻繁にパケットがやり取りされる双方向通信に於てボトルネックとなる。ネットワークリソースにまつわる課題である。
これがHTTP/2ではPersistent Connectionを前提としている。つまり双方向通信ありきの常時接続していることを前提としたプロトコルである。
このHTTP/2で動作することにより次の二つの特徴がgRPCにある。
・コネクションを常時接続にできる。
・データをバイナリにシリアライズすることで、転送量を圧縮
③通信方式として、複数のストリーミング形式を選択できる：
UnaryRPCという通常の１つのリクエストに対して１つのレスポンスを返す方式に加えて以下の通信方式がある。
・クライアントストリーミングRPC：クライアント側から複数リクエストを送り、サーバから1つのリスポンスを返却
・サーバストリーミングRPC：クライアント側から１つのリクエストを送り、サーバから複数のリスポンスを返却
・双方向ストリーミングRPC：クライアント/サーバ双方が複数のリクエスト/レスポンスをやり取りする方式
gRPCについてのデメリットは、バイナリに通信をシリアライズするため、レスポンスの確認には専用のクライアントツールが必要であることと、IDLの準備が手間であることが挙げられる。
前者はレスポンスを確認しただけではバイナリで読めないのでRESTと違い専用ツールを用意しないといけない手間がある。
後者に関しては手軽な開発とのトレードオフになる。
ここまで書いてみて
RESTは誕生当時、画期的な技術であったし現在も生き残っていること自体すごい。しかし、マイクロサービスや双方向通信が流行っていくようになりRESTが築いた地位をそのデメリットを解消する形で他のWEB APIにとってかわられるのは見ていて感慨深い。
双方向通信やマイクロサービスなどの技術が出てきて、今は普通になっているLINEやFacebookでのメッセージのやり取りが可能になっている。
ここでの学びは技術は完成をしない、時代によって求められるものによって進化を要求されたり淘汰される。
そうした完成されない技術の上に載っているサービスと、不完全ながら新サービスを生み出す技術のバランスの上に人の生活様式が乗っていると考えると、技術は面白いと感じるしさらに知りたいと思う。
また、今後の変化についてもどうなるか考え続けてみたいと思わせる魅力がある。人間の今時点での英知の集合体について気づける書く習慣はとても楽しい。
以上。読んでくださりありがとうございました。
この記事が気に入ったらサポートをしてみませんか？