#API色々あるやないかい
APIが色々種類あることを知り何がなんだかわからなくなるので整理メモ。間違いがあると思います。詳しい方ご指摘あったら遠慮なくお願いします。
概念的な部分にとどめているので詳しいAPIなどは書いていないです(ざっくりしてます。)
走り書きなので文字ばっかりです。
ーーーーーー追記ーーーーーーー
改めて見ると、WebAPIとAPIを区別せずに書いているので区別していきます。
今回は
- REST API
- ODATA API
- ADO.NET
- Open API
- SOAP API
- GraphQL
- gRPC
の7種類について簡単にまとめます。
#REST API
REST API = REpresentational State Transferの略。
RESTの原則に従って設計された設計モデル。(オブジェクト志向みたいなものかな。。)
あくまで設計思想のようです。
以下の4つが基本的な考え方
-
Stateless:セッションなどの状態管理を行わずやり取りされる情報はそれ自体で完結。ステートレスなクライアント/サーバプロトコル。
- 簡単にいうと、個々のHTTPリクエストが完全に分離していること。前のHTTPリクエストと今回のHTTPリクエストは影響を受けないよ。前のHTTPによって今のHTTPの処理が変わることはない
- Uniform Interface:情報の操作(取得・作成・更新・削除)はHTTPメソッド(GET・POST・PUT・DELETE)で行われる
- Addressability:リソース(データ)を一意に識別するURLの定義
-
Connectability:アプリケーションの情報と状態遷移の両方を扱えるハイパーメディア(リソースリンク)というやつが使える
- リソース(データ)に他のリソース(データ)へのリンクを含めることができるらしい
これをもとにして作られたWebシステムのHTTPの呼び出しインターフェイスをREST APIというらしい。
#ODATA API
Open Data Protocolの略でRESTfulなWebAPI(Webサービス)プロトコル。
OASISという規定に従って作られたプロトコル。つまり、OData特有の書き方があるということか。今はマイクロソフトが主導となって進めている模様。
Excelとかでデータ連携する場合にODataがあったりする。
HTTP↓
GET http://services.odata.org/v4/TripPinServiceRW/People HTTP/1.1
OData-Version: 4.0
OData-MaxVersion: 4.0
これはODataのHPに色々あるからそれを見るのが一番か
初めての人向けとかがわかりやすい
#ADO.NET
Wikipediaによると
従来のADOを.NET Framework環境で動作させるためのAPIとして提供された。
なるほど。ADOと.NET Frameworkってなんだ?
###ADO
Microsoftが提供しているActiveX Data Objectsの略でMicrosoft データ アクセス プログラミング モデルのこと。主にインターフェイス。マイクロソフトが提供しているデータにアクセスする際に使われるインターフェイス のことかな
###.NET Framework
Microsoftが開発したアプロケーションの実行・開発環境のことらしい。
OSやハードウェアを意識することなくいろんな言語でアプリケーションの開発が可能。Javaでいう仮装マシン環境(JVM)みたいなものか。
話は戻って、
つまり、ADOっていうインターフェースを.NET Frameworkっていう実行・開発環境で使えるようにしたAPIのことか(なんだかSDKみたいだな)
#Swagger
RESTが設計思想であり、そのためにそれに基づいたインターフェイスなどのREST-APIが多く存在するようになった。色々ありすぎて困っちゃうので”Open API Initiative”っていうREST-APIの仕様をしっかりと決めようという動きが出てきた。そこで採用されたのがSwagger。
主な使い方はトップダウン形式とボトムアップ形式がある。
###トップダウン形式
Swagger Specification(RESTFul APIインターフェイスを記述するフォーマット)を編集・定義
↓
そのインターフェイスを使ってソースコードの作成
###ボトムアップ形式
もうあるREST-APIからSwagger Specificationを定義
↓
作成したSwagger Specificationを使ってREST-APIをドキュメント化
なるほど。
#SOAP API
SimpleObject Access Protocolの略。リクエストとレスポンスはどちらもXMLフォーマットのデータで行う。SOAPはプロトコル。またRPCというのを使ったプロトコル。でもHTTPでもいける。
利点として異なるOS同士をXMLで疎通ができる。その時にHTTPを使うようだ。
RESTが
GET http://ホスト名/リソース(データ)名
であるのに対してSOAP APIは
http://ホスト名/サービス名/メソッド名
となり、最後がメソッド名でここで何をするか(動詞のよう)決まる
####特徴
- 拡張性:XMLがカスタマイズしやすく拡張しやすい
- 中立性:いろんなプロトコルで使える
- 独立性:どんなプログラミングモデルでも使える(オブジェクト指向型とか関数プログラミングとかいろんなモデルどれでも使えるよ)
#GraphQL
REST APIで不便なところを解消してくれるそうです。JSONで返します。
- データのリクエストが楽
- REST APIだと欲しい情報以外も持ってきちゃう。名前だけとかIDだけとか持ってこれる
{
me {
name
}
}
{
"me": {
"name": "Luke Skywalker"
}
}
- 1クエリで処理できる
- データ構造の中に関連オブジェクトをネストできる
- 例GraphQL)Happy New Year と投稿した人の写真ならHappy New Yearを探すところに写真をとるコードをネストする(1回送ればよし)
- 例REST API)Happy New Year と投稿した人の写真ならHappy New Yearの人を探してきて、そのIDとかで画像を探してくる(2回送らないと)
- データ構造の中に関連オブジェクトをネストできる
- クエリの検証が楽
- データのリクエストの時とかに名前とかを指定して取ってくるから言うなればString型みたいなもの。そこにintとか入らないよね。int入りそうになったらエラーでる。(インターフェイス とか実装した時楽ね)
#gRPC
Googleが開発したHTTP/2を標準でサポートしたRPCフレームワークです。
IDL(インターフェース定義言語)という言語に依存しないものを使って先にAPI仕様を作ってしまうらしい。その後各言語で実装。
おー便利だ。
.protoというファイルにインターフェースなどを記述するため、実装の段階でREST APIの時にしてしないといけないものや通信方法を気にしなくていいらしい。
#参考にさせていただいた記事
ありがとうございました。
- 「今さら聞けないWebAPIの実装方式RESTとSOAPの違い」https://qiita.com/pink/items/f1a22840619d3b79c4f2
- 「RESTful APIとは何なのか」
https://qiita.com/NagaokaKenichi/items/0647c30ef596cedf4bf2 - 「リソース指向アーキテクチャ(ROA)とは何なのか」
https://qiita.com/NagaokaKenichi/items/0f3a55e422d5cc9f1b9c - 「ODataにさわってみよう」
https://www.cresco.co.jp/blog/entry/3135/ - 「SwaggerでRESTful APIの管理を楽にする」https://qiita.com/disc99/items/37228f5d687ad2969aa2
- 「なぜポストREST APIが求められるのか? REST APIがカバーできない2つの要因とその対策」http://kageura.hatenadiary.jp/entry/2018/01/11/%E3%81%AA%E3%81%9C%E3%83%9D%E3%82%B9%E3%83%88REST_API%E3%81%8C%E6%B1%82%E3%82%81%E3%82%89%E3%82%8C%E3%82%8B%E3%81%AE%E3%81%8B%EF%BC%9F_REST_API%E3%81%8C%E3%82%AB%E3%83%90%E3%83%BC%E3%81%A7%E3%81%8D
- 「GitHub APIから学ぶ次世代のAPI実装方式GraphQL」https://qiita.com/icoxfog417/items/92214aed64f47dfeade5
- 「gRPCって何?」https://qiita.com/oohira/items/63b5ccb2bf1a913659d6