APIs as a Product: Get the value out of your APIs / Red Hat Developer

API as a Product の流れが実際に実装に現れてきたのを感じています。人に説明する前に他の人はどう説明しているか? 自分が正しく理解しているか? のために確認しました。内容的には簡潔にまとめられた良い説明だと思います。

これを読みたかったのはAPI as a Productの考え方のもとに提供されたAPIプログラムが増えたなと思ったことなんです。

以下は過去から現在に渡って自分が体験したAPIプログラムの変遷について。

過去: アプリケーションのバルク処理用の口のイメージ

昔はAPIと言ったら、なんらかのアプリケーションのバルク処理用のジョブを投げる口のイメージが強かったです。

例えば15年ほど前に扱ったService Management基盤やProject Portfolio Management基板などのAPIは、APIが実装されたのがそもそもSOAPが主流だった頃です。

SOAP全盛期のAPI (当時はWeb Serviceと言っていた) は、まず基本のアプリケーションがあって、ユーザーが使うUIがメインのインターフェース、APIはあるだけいいよね、と言った感じでした。

当時APIの扱い方のドキュメントは非常に薄く、説明も充実していなくて、使い方を把握するには

1. ユーザー用UIでユースケースやデータモデルを理解
2. ドキュメントをみてよく分からなくて困ってみる
3. Soap UIにWSDLをロードし、理解したデータモデルやユースケースと照らし合わせる
4. API固有のメソッドはとりあえず何かテストリクエストを投げてみてレスポンスをみてみる

の流れをとっていました。3まできて初めて自分がしたいことがAPIで出来そうかわかるわけです。WSDLでの把握が苦手だったのが災いしました。また当時のパッケージアプリケーションのAPIはカラムが足りなかったりもしたので、できるだろうと思っていたことができなかったりはちょくちょくしたものです。

当時のAPIの設計はメソッド式で、例えば GetUserDetails のようなURIを作って、API開発者がAPIクライアント開発者に対して提供したい機能をメソッドやファンクションのような形で提供するのが一般的でした。

数年前: CRUDのAPI


API ExplorerやSwaggerが出たときには便利になったなあと思ったものです。

CRUDのAPIの良いところは、基本的にはHTTPのどこに何を入れればどうなりそうかがわかりますし、かつ設計がオブジェクトベースなので、ドキュメントを見ればデータモデルがある程度把握出来たのが便利でした。

ただし、今の状況と比較すると、「これから開発者が開発するAPIクライアントのパーツ」感があったことに気が付きました。

現在: API as a Product

では数年前と比較して今どうなっていることに気がついたかというと、

- メソッド/ファンクション式の設計が増えたが、おそらくCustomer Journey MappingやUser Story Mappingを使って検討したような成熟度の高いメソッド/ファンクション式になっている
- 料金体系がAPIの存在意義に見合ったものになっている。トランザクションベースの料金体系が減り、1ユースケースあたりいくら (ユースケースあたりのトランザクション数は複数になる) が増えた
- ドキュメントがCustomer Journeyを意識したものになっている

したがって、ドキュメントをみたときに「なんとかなりそうだな感」がありますし、料金体系みたときに納得感があります。

じゃあ CRUD (REST) APIってなんなの?

CRUD式APIの設計のベストプラクティスってオブジェクトベースの設計なのですが、成熟度の高いメソッド/ファンクション式の設計も同じく “REST” と呼ばれています。

という中において “REST” って、「HTTPの機能を使ったAPI」レベルの位置付けになりつつあるように思います。そもそも論で言えば一般で言われているRESTは論文に定義されたRESTではないですし、意味が移ろいやすいのは仕方がないかなと思います。

一方でオブジェクト型と言えば、GraphQLの実装が増えました。

データサービスとしてのAPIであればGraphQLの方が使い勝手がいいですし、よりデータベースライクに使えるところがとても良いです。

今行われているAPI DaysでもGraphQLのセッションが多いので、注目は高いのではないでしょうか。

というところを考慮すると、

- 今後データサービスとしてのAPIはGraphQLに寄っていくのでは
- “REST (CRUD)” はメソッド/ファンクション型の設計に寄っていくのでは

というあたりを先々数年ウォッチしてみたいと思います。

この記事が気に入ったらサポートをしてみませんか?