拡張可能なWeb APIの設計原則と、バージョン番号を使う理由について

APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sightにはブコメしたのですが、Rebuild: 35: You Don't Need API Version 2 (Kenn Ejima)でも本件に言及があったようなので、少し一般論を書いておきたいと思います。 ■Web APIの設計原則について そもそも、良いAPIとはどのような特性をもつものでしょうか？ 一般的に、以下の２点が挙げられると思います。 拡張が容易である 拡張時に後方互換性を破壊しない ウェブの場合は、これに加え、 スケーラブルである HTTPに起因する問題に上手に対処できる ことが求められます。 前２者はウェブに限らない要件です。これを満たす設計手法としては、 リクエストおよびレスポンスのパラメータを拡張可能に 互換性を壊す拡張が必要な場合は、関数名を変える 古い関数は従来と同じ機能を

[johnmayer]

APIに対する全リクエストにバージョン番号が含まれ、サーバサイドのログにも残るため、問題の切り分けが容易

[koheisg]

この記事を読みたかったんだよな。あんなに説得力があったのに、自分が人に説明できなかった。

[Dai_Kamijo]

メモ — 上條　大 (@Dai_Kamijo) January 15, 2015 from Twitter http://ift.tt/1GCLN1f January 15, 2015 at 12:32PM via IFTTT

[teppeis]

POSTパラメータよりURLの方がログで利用状況見るのが格段に楽なんですよね。

[t-wada]

kazuho さん semantic versioning にも言及していてさすがだ

[raimon49]

＞APIに対する全てのリクエストにバージョン番号が含まれるため、「クライアント側でバージョンチェックを怠った」がゆえのエラーは発生しようがありません。また、サーバサイドのログにもバージョン番号が残る

[efcl]

/v1/ について。 URLなので必ずバージョン番号が含まれるのが便利

[nilab]

Kazuho's Weblog: 拡張可能なWeb APIの設計原則と、バージョン番号を使う理由について

[hoisjp]

クライアントへのおもてなしレベルが最も高い、ということか。

[futtafutta]

参考になった B!

[TokyoIncidents]

APIに対する全てのリクエストにバージョン番号が含まれるため、「クライアント側でバージョンチェックを怠った」がゆえのエラーは発生しようがありません。また、サーバサイドのログにもバージョン番号が残るため、管

[yass]

" クライアントが「廃止された」APIに依存しているかどうかは、サーバサイドでないとチェックできない / クライアントアプリケーションの開発者は、しばしば「バージョンチェックを怠る」"

[yosuke_furukawa]

目の前にブログ書いた人がいるの直接質問できて便利

[kazuhooku]

blogged