APIの後方互換性を保つ工夫

http://www.heavybit.com/library/developer-technical/video/2014-09-30-amber-feng

1 comment | 2 points | by WazanovaNews 約3年前 edited


Jshiike 約3年前 edited | ▲upvoteする | link

Stripeの決済サービスの成長は、APIが使いやすいというエンジニアの間での評判がかなり寄与したと記憶しています。

同社のAPIは現在、

  • エンドポイント: 106
  • バージョン: 65
  • APIクライアント: 6

ユーザ企業を煩わせることなく後方互換性をしっかり担保したいという方針を守るための工夫を、Amber Fengが紹介してくれています。

1) ユーザが利用するバージョン情報の把握

ユーザ企業が最初にAPIコールをしたときのバージョン情報をStripe側で記録している。ユーザ企業はバージョンのことを意識することなく、それ以降は、最初のバージョンのAPIを継続して利用し続けるかたちになる。もしユーザ企業側でバージョンの変更をしたい場合は、ダッシュボードでの設定や、リクエストヘッダーに情報を付加することで可能。

2) バージョンと機能の整合性

YAMLファイルでバージョンとその振舞いの情報を管理しているが、そこで指定したゲートと呼ばれるデータベースフラグを利用することで、既存のAPIにおいて後から変更された仕様を適用できる仕組みにしている。(ブログに参考コードが記載されてます。)ユーザ企業が、追加された新たなAPIをコールする場合は、強制的に最新のバージョンを利用することになる。

互換性のフィルターをAPIロジックの前後に配置している。まずリクエスト互換性のフィルターが、ゲートで追加された新しい仕様のパラメータに合致しているかチェックしたり、新しい仕様に合ったパラメータに転換したりしている。そして、APIロジックを経由してレスポンスが用意作成されると、最後にレスポンス互換性のフィルターが適用され、ユーザの該当するバージョンの最新のかたちにレスポンスを変換している。

3) ドキュメントの自動化

ドキュメントの更新漏れがないように、コードの中で変更忘れのまず起きない箇所の情報(コード例)から、ドキュメントを自動生成している。

#stripe #api


ワザノバTop200アクセスランキング


Back