Java クライント開発におけるWeb API の実装アプローチ：その1 Web API を活用する上で意識したい APIエコシステム
最近個人的に気になったトピックとして、世界のAPI Management 市場規模のニュースがありました。
Global API Management Market Worth USD 3,436.16 Million by 2022
サイトから引用
このニュースによると、世界のAPI Management 市場は2022年までに現在の2倍（3,000億円）の市場規模になると予想されていて、「これから2倍以上もAPIが出てくるかもしれないのかぁ」と想像がつかない部分と、ワクワクした部分が同居したような感覚になったのをよく覚えています。
もちろん、API Management 系ですので、一律すべてパブリックに公開されるわけではないでしょうが、今後今まで以上にAPI を使ったマッシュアップは重要性を増すことは間違いないように思います。
しかしながら、API Management もそうですが、同じように最近よく取り上げられる「API エコシステム」についても、以下の記事にあるように提供者側を中心としたトピックではないでしょうか。
でも、APIは最終的に使うユーザー・デベロッパーが居て、はじめて真価を発揮するものですが、使う側としてこういった API の流れ、API エコシステムに対していAPIを使うデベロッパー側はどのように関わるべきか？ 意識するべきか？ というお話はあまり多くありません。
そこで今回 API を使う側にとっての API エコシステムをテーマに、様々な API のスタイル・プロトコルを Java のクライアント実装ベースで触りながら、それぞれの特性・エコシステムの特徴について、何回かに分けて連載をしていきたいと考えています。
今の所予定では、こんな感じです。
1. 一般的な REST API に対して HTTP Client ライブラリを利用する場合
2. Swagger（OpenAPI）Code Generateを利用する場合
3. OData ライブラリを利用する場合
4. GraphQL エンドポイントを利用する場合
5. CData JDBC Driver を利用する場合
6. まとめ
今回は初回ということで、そもそもなぜデベロッパーが API エコシステムを意識する必要があるのか？といった、このBlog記事をはじめるにあたって背景となった考えを述べていきたいなと思います。
なお、このBlogでは便宜上、API提供側をプロバイダー、API利用側をデベロッパーと書いています。
そもそもなぜデベロッパーが API エコシステムを意識する必要があるのか？
例えば、Microsoft のビジネスクラウドアプリケーション Dynamics 365（CRM）はC#とVBのSDKが公開されています。
なので認証周りや API 仕様を知らなくても、.NET 技術者は実装がしやすいのではないかなと思います。
では、Java や Python のデベロッパーは大人しくHTTP Client系ライブラリを使って実装するしか無いのか？ というと、そういうわけではありません。（もちろんその実装アプローチを否定するわけではありません）
そこで一つ目を向けてほしいのが、Dynamics 365 の API は「OData」という仕様で公開されている、という点です。
以下は OData の公式サイトにあるエコシステムページです。
Ecosystem · OData - the Best Way to REST
ここに掲載されているのは、OData を提供しているプロバイダーと、ODataを使いやすくするためのサービスやツール、ライブラリの一覧です。
探してみると、これらの中に Java や Python のクライアントライブラリも書かれているのがわかるかと思います。
これらライブラリを使うだけでも、純正ではないにせよ、実装のしやすさは格段に違うものになるのではないでしょうか。
他にも、例えば電子契約サービスの クラウドサイン ではOpenAPI （Swagger Hub）でドキュメントが公開されています。
https://app.swaggerhub.com/apis/CloudSign/cloudsign-web_api/0.8.0
もちろん、これだけでも API 仕様書として見やすいことこの上ないのですが OpenAPI をベースとした Swagger Hub では Client SDK の自動生成もサポートしています。
これで Java のソースコードを生成すると、各 API Responseとなる JSON Object の デシリアライズ用 Class 生成からリクエストテストコードまで生成してくれます。
このように、API のエコシステムを知っているだけで、開発スピードに雲泥の差が出てしまうのがイメージできるのではないかと思います。
また、単純に API を REST API と表現してしまう危うさがここにあります。
REST API は「仕様」では無いため、APIの構造を元にSDKを生成したり、共通のライブラリを元に様々な Web API にアクセスできるようには提供されていません。
各プロトコルやAPI ドキュメント系特有のエコシステムが発生しづらい原因がここにあります。
なので、これから取り上げる各仕様（Swagger・OData・GraphQL）に準拠しない場合、純正のSDKを使うか、自身でHTTPベースのやり取りを実装しなければいけません。
おわりに
初回はざっくりと、全体像のお話に終始しました。
次回から実際の実装コードも踏まえながら、見ていきたいと思います。
ちなみに、今回は「gRPC」「XML-RPC」「JSON-RPC」「SOAP」などのプロトコル郡には触れないです。RPC系は社内システム間での連携の側面が強いのと、SOAPも最近めっきり聞かないですしね。
