Apiary - r7kamura per second
API(とそれに携わる開発者)の規模が拡大してくると、ドキュメントの整備や、仕様と実装の一貫性の維持、 クライアントとの知識の共有など、考慮すべき問題が沢山出てくる。 これらの問題に対する現実的な解決策を探るため、 ApiaryというAPI開発支援用のサービスを簡単に俯瞰することにした。 ここでは紹介しないが、他に RAML、 JSON Schema、 Swagger、 WADL、 Autodoc などが関連するものとして挙げられる。 Apiary http://apiary.io/ Apiaryは、API Blueprintと呼ばれる言語でAPIのインターフェース仕様書を記述する、という開発方法を提唱している。 API BlueprintはMarkdownを拡張した言語で、特殊な記述を用いて幾つかのメタ情報を付与出来る形になっている。 Markdownを採用することで人間にとって読み書き
APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sight
ちょっと前にTwitterでAPIのバージョニングをどうやるかみたいな話をしていたのですが、そのへんもやもやしているので少し整理しておきたいなと。 APIのURLを/api/v1/*とかってやるの、やめたほうがいいとおもうんだけどなぁ。いざv2を作るとなったときに、大量のコピペが発生して後悔するよ、って伝えたい。— Kenn Ejima (@kenn) February 28, 2014 さて、これについて色々と異論・反論も含めた意見が出たのですが、まずは、大昔にURL方式（＝コントローラ分割）でやってきて後悔したぼくが、（5年ぐらい前から）現在はどうやってAPIのバージョンを管理しているか？について紹介します。 基本原理としては、コピペが多発する根っこで分岐（＝コントローラ分割）じゃなくて、必要最小限のところで限局的に分岐するのがいい、という考え方に基づきます。 一言でいうと、「パラメー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
