SDK、ライブラリのメリットデメリット

APIにはHTTPアクセスをそのまま提供するだけのものもありますが、SDKや専用ライブラリを提供しているものもあります。今回はそんなSDK、ライブラリを利用する（または提供する）メリット、デメリットを挙げたいと思います。

メリット

利用者側の視点で考えた場合、次のようなメリットが考えられます。

HTTPアクセス部分を意識しないで済む

APIにおけるHTTPリクエストの作成を意識しないで済むようになるのがSDK/ライブラリのメリットです。特にOAuth2リクエストのように署名を生成するような部分は実装が面倒、かつ検証も大変なのでメリットがあります。

これは提供側にとってもメリットがあります。自作ライブラリでのアクセスは当然エラーが頻発します。また、予想外のアクセス方法をしてくるかも知れません。SDKであれば、自分たちが開発している範疇でのアクセスに限定されますので、パフォーマンスを向上させる計画も立てやすくなります。

APIのバージョンアップを気にしない

APIをバージョンアップした際には項目が追加または削除されたり、構造が変わったりする可能性があります。HTTPアクセスを通して使っている場合、こういった変化がシステムエラーにつながるためにバージョンアップを躊躇してしまいがちです。

SDKを使っている場合、そうした差分はSDKで吸収できます。SDK側で過去のバージョンに合わせたレスポンスに加工しておくことで、不用意なエラー発生を防ぐことができます。

デメリット

SDK/ライブラリの提供によるデメリットは多数あります。このため、開発者によっては導入を控えてしまうと言うのはよくある話です。

SDK、ライブラリのバグ

SDK、ライブラリがバグを含んでいたりすると、開発者にはとても嫌われる要因になります。開発者は自分の開発した範囲については責任を持ちますが、それが他者の開発したコードに起因するものだとするととてもストレスを感じるものです。

特にスマートフォンアプリの場合、修正と審査によって時間がかかるため、修正が即座に反映されません。そのため、SDKがバグを多く含んでいる場合、開発者はサービス自体の利用を止めてしまう可能性があります。

提供側としてはバグを含めないようにするのはもちろんのこと、省メモリであったり、サイズを小さくする、オープンソースにすることで開発者自身が原因を調べたり改善できる可能性を残すと言った回避策が考えられます。

特にSDKの場合、ネットワークがオフラインである場合を考慮して開発する必要があります。APIはネットワークがなければ意味がありませんが、オフライン時にメソッドをコールしても正しく動作し続けなければなりません。

動作が重たくなる可能性

SDKのサイズが大きかったり、余計なことをしているために動作が重たくなることがあります。開発者としては自分の作成したシステムやアプリが重たくなるのは嫌います。それがSDKのようにブラックボックス的に使っている部分だと特にです。

もちろん、SDKによって動作が軽くなると言うのは難しいですが、全体のコード量を減らせる可能性はあります。提供側としてはそういった視点で開発する必要があるでしょう。

更新が面倒

SDK/ライブラリが頻繁にアップデートを繰り返す場合、開発者はアップデートが面倒に感じてしまうものです。せめてパッケージ管理システムを利用するなどアップデートの手間を減らすべきです。

また、SDK/ライブラリレベルでのインタフェースは統一しておかなければなりません。インタフェースが変わってしまうとコードの修正が必要になりますので開発者にとって大きな負担となります。そのため引数も直接指定するのではなく、ハッシュを使って柔軟に設定できるようにしておくなどの工夫が必要です。

他のライブラリとのコンフリクト

SDK/ライブラリによってはさらに外部ライブラリを使っているケースがあります。また、Webサービスやスマートフォンアプリは他にもたくさんのライブラリを導入しているでしょう。そうした外部ライブラリとコンフリクトを起こすのは危険です。開発者は取捨選択しなければならないからです。

時に、ライブラリの読み込み順番によってエラーが出たり出なかったりするケースがありますが、これは開発者にとって大きなストレスになります。SDKの信頼性にもつながるでしょう。

提供側としては自分たちのコードだけでなく、外部ライブラリとの組み合わせによるテストも行わなければならないでしょう。

SDKインタフェース

SDKやライブラリはただ動けば良いという訳ではなく、そのインタフェースや設計思想が開発者に与える印象は大きいです。SDKはモダンな開発手法を使い、インタフェースもモダンである必要があります。

モダンな開発手法もトレンドがあります。パッケージ管理も状況が変わります。そうした開発トレンドに合わせてバージョンアップしていく必要があるでしょう。

開発コスト

提供側にとって大きな問題は開発コストです。プログラミング言語は多数あり、どれに対してライブラリを提供するかが問題です。一度の提供は簡単ですが、バグフィックスであったり、APIの更新に合わせた修正は大きなコストにつながるのでライブラリのプログラミング言語の選定は注意が必要です。

APIの利用を広める上でSDK/ライブラリの提供は大きな意味を持ちます。しかしその品質によっては開発者の信頼を大きく損なったり、API自体の採用を控えてしまうことになりかねません。提供側としてSDK/ライブラリを提供する場合は慎重な設計と品質、パフォーマンスに十分気を配る必要があるでしょう。