1

重複の可能性:
REST URI のバージョン管理方法

私は REST に準拠した API 設計に慣れていないため、REST に準拠したスタイルで API のバージョン管理を実装する方法について、コンセンサスを見つけることができないようです。私が遭遇した可能性は次のとおりです。

  • URL ベース (例: /myApi/version5/someCall)

    このアプローチは、サーバーとクライアントの両方でうまく機能します...しかし、REST にあまり対応していないようです (URL はリソースに対応するはずであり、API バージョンは実際にはリソースの一部ではありません)。

  • ペイロードベース (例: $.ajax({data:{version:5, ...)

    このアプローチは、互換性に関しては優れていますが、次の点に注意してください。

    A) サーバーは実際にペイロードを解析してバージョンを判断する必要があります (これにより、バージョン チェック ロジックが必要以上に「深く」配置される傾向があります)。

    B) 繰り返しますが、私が哲学について言えることから、これはあまり REST に依存していません (私が理解しているように、POST するデータは、作成したいリソースのデータのみである必要があります)。

  • ヘッダーベース (例: Accept application/json;version=5)

    このアプローチはここで提案されました。これは、REST 対応の API を作成する方法に関する優れたリソースであることがわかりました。ただし、この特定のケースでは、問題が発生し続けます。何をしても、ヘッダーでバージョンを送信するようにjQueryを取得できないようです。

試してみれば、アプローチ #3 で最終的に jQuery の問題を解決できると確信していますが、ヘッダーベースのバージョン管理では間違った道を進んでいる可能性があると思いました。私が問題を抱えている場合、私たちの API の消費者もそうする可能性が高いようです。

したがって、REST-ful API を作成する場合、誰でもどのバージョン管理アプローチを説明できますか?

  • A) 他のテクノロジー (ブラウザー、フレームワークなど) と最適に連携します。

  • B）「REST-ful」哲学を最も忠実に実装する

  • C) が最も一般的です (これ自体は重要ではありませんが、最初の 2 つの指標になる傾向があります)。

言い換えれば、REST-ful API でバージョン管理を処理する最良の方法は何ですか?

4

2 に答える 2

2

解決策 1 は実用的で単純に思えます。参考までに、twitter( api.twitter.com/2) とlinkedin ( api.linkedin.com/v1) は URL ベースのバージョニングを使用し、Google Data( &v=1.0) はペイロード ベースを使用します。私の実践的な経験は、URL ベースのバージョニングです。

分析を行いたい場合は、このapi ディレクトリを確認してください

于 2012-09-12T13:50:38.133 に答える
1

私は解決策1を強くお勧めします、それは明確で簡単です-StackOverFlowでさえそれを使用するだけではありません：https ：//api.stackexchange.com/2.1/questions？order = desc＆sort = activity＆site = stackoverflow :)

于 2012-09-12T01:53:52.093 に答える