Google における API のバージョニング | Google Cloud 公式ブログ
API のバージョニングは簡単ではありません。いろいろな方法があり、API の世界の人なら誰でも持論をお持ちでしょう。バージョニングを避けることもほとんど不可能です。開発チームが仕事を進めると、機能を廃止（または、その機能を別の形で提供）する必要が生じることがあります。バージョニングを導入すれば、API のユーザーは API のセマンティクスの変化を確実に把握できるようになります。 複数のバージョンを設けないようにする会社もありますが、Google にはそのような余裕はありません。Google の API の数、API を開発しているチームの数、API を使っている開発者の数があまりにも多いので、どのような機能が API に期待されているのか、それを知るための手段として私たちは API をバージョニングしています。 API のバージョニングには一貫性のある包括的なポリシーが必要です。Goo
APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sight
ちょっと前にTwitterでAPIのバージョニングをどうやるかみたいな話をしていたのですが、そのへんもやもやしているので少し整理しておきたいなと。 APIのURLを/api/v1/*とかってやるの、やめたほうがいいとおもうんだけどなぁ。いざv2を作るとなったときに、大量のコピペが発生して後悔するよ、って伝えたい。— Kenn Ejima (@kenn) February 28, 2014 さて、これについて色々と異論・反論も含めた意見が出たのですが、まずは、大昔にURL方式（＝コントローラ分割）でやってきて後悔したぼくが、（5年ぐらい前から）現在はどうやってAPIのバージョンを管理しているか？について紹介します。 基本原理としては、コピペが多発する根っこで分岐（＝コントローラ分割）じゃなくて、必要最小限のところで限局的に分岐するのがいい、という考え方に基づきます。 一言でいうと、「パラメー
ライブラリのバージョニングのしかた - Islands in the byte stream
セマンティックバージョニングは守るとして、だいたいこんなポリシーでやってます。 0.0.1 - proof of concept / minimum viable product 0.1.0 - とりあえずリリースしてプロダクションに組み込んでみる 1.0.0 - プロダクションに組み込んだ 2.0.0 - セマンティックバージョニングに従うので、メジャーバージョンアップは機能ではなく単にAPI互換性を失うという印 あとは、alpha, beta, rcなどを接尾詞としてつけることもあります。 *-alpha - 開発中 *-beta - 安定してきた *-rc - release candidate. プロダクションに組み込んでもOK
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Web APIにバージョンをつけないように
