APIとは
APIとは「Application Programming Interface」の頭文字です。
要約すると「アプリケーションをプログラミングするためのインターフェース」といった感じでしょう。
インターフェースって何だ・・・？
インターフェースとは「異なる機器・装置のあいだを接続して、交信や制御を可能にする装置やソフトウェア。」という意味でした。
つまりAPIとはアプリケーションとプログラムをつなぐものです。
より簡潔に言うとソフトウェアの機能を共有することができる仕組みです。
具体的な話をするとExcelを外部プログラミングから入力出力させたり、プリントドライバーを呼び出し印刷処理をすることもAPIの１つです。
またWebAPIの場合はHTTP/HTTPSを採用し、OSという垣根を超えて使われています。
APIのメリットは何か
・開発効率の向上
・セキュリティの向上
・最新方法を自動で取れる
開発効率の向上
今から作る機能がすでにAPIで公開されている場合、自分で作る必要がなくなるため作業時間が大幅に削減されます。
作業時間が減ることで違う工程に時間を使うことができます。
セキュリティの向上
フェイスブックやTwitter・Instagramなどアカウントを利用してあるサービスでログインできた経験はみなさんあると思います。
開発側として自社で会員登録するシステムを作らなくてもセキュリティの高い会員登録システムを利用することができます。
またユーザー的にもわざわざ会員登録をしなくても良いと言うメリットにも繋がります。
正しい情報を提供できる
APIを利用することでそれぞれのサービスの最新の情報を自動で更新することができます。
自ら更新する手間を省かれます。
またgoogleMapなどのAPIを利用することで自分で作成した地図よりも正確ですし、口コミなどもSNSの情報を利用した方が信憑性が高まります。
WebAPIとは何か
Web APIはサーバ側が提供するプログラム機能をインターネットを通してクライアント側で呼び出すことで実行されます。
WebAPIの呼び出しは通常のWebの仕組みを用いて実行します。
URLを指定してHTTPを通してリクエストを送ることがWeb APIと呼ばれます。
そのため異なるプログラミング言語で開発されたアプリケーションとの連携ができるようになる。
WebAPIの受け取る結果は、XMLやJSON形式が用いられることが多いです
WebAPIの歴史
1.いろんなシステムで強調して動かしたいものがあるよね
2.相互に機能の呼び出しなどを行えるようにする手順を定めた規格を作ろう
めちゃたくさん規格が乱立(CORBA, DCOM, RMI, WMIあたり)
これらをまとめてRPC(Remote Procedure Call)と呼ぶか
2-1. RPCとは
RPC仕様では呼び出し側、手続き側の双方がRPCによる呼び出しに対応するためのAPIと、ネットワーク上で呼び出し要求メッセージや応答メッセージを送受信するための通信規約（RPCプロトコル）を定めている。同じRPC仕様に準拠した仕組みを採用していれば、機種やOS、プログラミング言語などが異なっていても共通の手順で呼び出すことができる。
3.てかプロトコルとかめんどくね？
じゃあWeb(HTTP)で統一しようぜ → SOAP誕生
4.受け取る側がどんなメソッド持ってるか知らんと呼べないやん
リソース自体もとって来れれば操作できるね → REST誕生
5-1.RESTだとリソースの数だけHTTPアクセスしなあかん。キッツ！
HTTPで統一してるのはいいけど、その苦労はもういや → GraphQL誕生
5-2.てかいつまでもHTTPでやってることが無駄じゃん
独自のプロトコルに戻ろう → gRPC
って感じの歴史です。
SOAP
webAPIではもともとXMLをデータ形式としSOAPというプロトコルが利用されており、多くは企業同士のシステム連携などに使われていました。
しかしプロトコルのため複雑性とオーバーヘッドが大きく、双方の負荷が高くあまり普及されませんでした。
RESTとの違いをお伝えすると、SOAPは規格が決まっており、RESTは設計思想という大きな違いが存在します。
そのためRESTではRESTfulといった言葉が存在し、RESTの思想に従うかは開発者に委ねられています。
余談ですがSOAPとRESTを比較した記事を見て学んでしまい混乱してしまいました。
そもそもSOAPはプロトコル、RESTは思想なので比較すること自体が誤りだと感じました。
REST
RESTとはRepresentational State Transferの略です。
セッションなどの状態管理を行わず、やり取りされる情報はそれ自体で完結して解釈することができる」（WebではHTTP自体にはセッション管理の機構はない）、「情報を操作する命令の体系が予め定義・共有されている」（WebではHTTPメソッドに相当）、「すべての情報は汎用的な構文で一意に識別される」（URL/URIに相当）、「情報の一
部として、別の状態や別の情報への参照を含めることができる
http://e-words.jp/w/REST.html#Section_%E6%9C%AC%E6%9D%A5%E3%81%AEREST
Web上で提供されるサービスのHTTPプロトコルにおけるやり取りをまとめたものです。
HTTP上でリソー スに対応するURIへの操作としての追加・編集・削除をHTTPメソッドのGET・POST・DELET等を結びつけてやり取りします。
とてもシンプルであり、拡張性も高いことから最も多く使われています。
REST4原則
上記の概要からもわかるようにRESTには4つの原則があります。
・アドレス可能性
アドレス指定可能なURIで公開されており全ての情報が一意なURIで表現されていることです。
あくまでもリソースをアドレス配置できることであって、取得や更新といった行為はHTTPメソッドで指定するもの。
アドレスはリソースを示す名詞で成立して、動詞はHTTPメソッドに紐づけられます。
・ステートレス性
すべてのHTTPリクエストが完全に分離している性質であること。
セッションなどの状態管理は行われないこと。
サーバー側でクライアントの情報を保持しない。
・接続性
ある情報に「別の情報へのリンク」を含めることができること。そして、リンクを含めることで「別の情報に接続すること」ができる。
・統一インターフェース
リソースに大して操作するためのメソッドはHTTPで定義されているGET、POST、PUT、DELETE、HEAD、OPTIONS、TRACEのみを使用する。
GraphQL
GraphQLは歴史でも書いたようにRESTの課題であったように複数のAPIリクエストが必要という点を解決しています。
RESTの場合、複雑なリソースが必要な場合は複数のAPIリクエストが必要であり、その分コードが複雑かしていきます。
GraphQLは、欲しいリソースを一度のリクエストで取得できます。
また、RESTのように動詞やURIに頼らず、取得したいリソースをHTTPPOSTのbodyに記載してリクエストします。
とてもわかりやすいイメージがあったので添付させていただきます。
▼REST
デスクトップ・iPhone・Android・タブレットに対応した開発するためには全ての環境から取得する必要がありました。
▼GraphQL
一方GraphQLは、標準化された言語と仕様を持ちクライアントとサーバーを結びつけます。
そのため異なる環境であっても取得はとてもシンプルになり、クロスプラットフォームのアプリ開発等も非常に楽になります。
gRPC
gRPCは文字どおりRPCの技術を採用しています。
もう一度RPCの説明するとクライアント-サーバー型の通信プロトコルでサーバー上で実装された関数をクライアントから呼び出しで実行します。
ただどのようにクライアントからリクエストを送信するか・どのようにフォーマットでやりとりをするかは日々変化し、たくさんの実装方法が存在しています。
なぜgRPCが生まれたのかというと、RESTなどはテキストベースでの情報やり取りをするためデータの転送効率が悪くオーバーヘッドが存在したりします。
そういった問題を解決するためにgRPCが考案されました。
gRPCはProtcolBuffersを利用してデータをシリアライズし、通信にはHTTP/2を使うことで高速通信を実現できます。
ProtcolBuffersとはGoogle製のインターフェース定義言語で.protoファイルにAPIの期待する入力・出力形式を定義します。
そのため、RESTで叶わなかった厳格な型付が可能です。
最後にgRPCの図を添付しておきます。
まとめ
APIそしてWebAPIの歴史から生まれた技術を話していきました。
技術をただ学ぶよりそれぞれ何が課題とされ何を解決するために考案されたのか流れに沿って学習することで、技術の特徴を理解することができました！
1つ1つの技術に対して深い知識を持っていないので、誤り等あるかと思いますが（無いようにはしてる）少しでも参考になればと思います。