APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sight
ちょっと前にTwitterでAPIのバージョニングをどうやるかみたいな話をしていたのですが、そのへんもやもやしているので少し整理しておきたいなと。 APIのURLを/api/v1/*とかってやるの、やめたほうがいいとおもうんだけどなぁ。いざv2を作るとなったときに、大量のコピペが発生して後悔するよ、って伝えたい。— Kenn Ejima (@kenn) February 28, 2014 さて、これについて色々と異論・反論も含めた意見が出たのですが、まずは、大昔にURL方式（＝コントローラ分割）でやってきて後悔したぼくが、（5年ぐらい前から）現在はどうやってAPIのバージョンを管理しているか？について紹介します。 基本原理としては、コピペが多発する根っこで分岐（＝コントローラ分割）じゃなくて、必要最小限のところで限局的に分岐するのがいい、という考え方に基づきます。 一言でいうと、「パラメー
Web APIの設計指針についての補足｜デロイト トーマツ ウェブサービス株式会社（DWS）公式ブログ
先日初めて、自分が書いたブログの記事、Web API設計指針を考えたがはてブでバズるという経験をしました。たくさんの方に読んでいただけたというのは非常にうれしいことです。ただ、設計指針には根拠を書かなかった箇所が多く補足したいところが出てきたため、以下の内容について根拠などを書いていきたいと思います。 バージョニングについて RESTfulについて バージョニングの設計・実装について 以下の指針を書きました。 APIにはバージョンをつける。 vと整数のバージョン番号をURLにつける。 バージョンは整数。マイナーバージョンは作らない。 例） http://api.example.com/v1/users 上記指針をRailsで実装する場合には、バージョンを上げるときにはコントローラごと分けるようにしています。 ただ、少々前の話になりますが、こんな記事がありました。 APIのバージョニングは限
You don't need API version 2 - yohei's diary
周回遅れ感が半端ないけどバージョニング関連で色々読んで・聞いて思ったことを書く。 APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sight Kazuho's Weblog: 拡張可能なWeb APIの設計原則と、バージョン番号を使う理由について Rebuild: 35: You Don't Need API Version 2 (Kenn Ejima) rest - Best practices for API versioning? - Stack Overflow RESTfulなサービスのバージョンングから得られた知見 RESTとバージョニング 基本的にいわゆる狭義のRESTとAPIのバージョニングは何も関係ない。強いて言えば、HATEOASはバージョニングにも使えるよ、というのがREST信者の主張であるものの、それが正しい（というか実用的）かど
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
