8

いくつかの例で、API をバージョン管理する 2 つの方法に気付きました。

そのうちの 1 つは、URL でバージョンを使用しています

/api/v1/products

もう 1 つは、コンテンツ タイプ ヘッダーと Accept ヘッダーを使用して、サーバーに送信されるデータの API バージョンをマークします。

Content-Type=application/vnd.company.v2+xml

このアプローチの長所と短所は何ですか? 各アプローチを使用するユースケースは何ですか?

4

3 に答える 3

8

どちらのメカニズムも有効です。従うべき道を知るには、消費者を知る必要があります。一般に、企業や学問に関心のある人々と協力する場合、開発者はリソース ヘッダーのバージョン管理を行う傾向があります。ただし、クライアントが中小企業の場合は、URL バージョン管理アプローチがより広く使用されています。

ここに私が見つけることができる長所と短所があります（もっとあると確信しており、一部の短所にはここで言及されていない回避策があります）

  1. より探索可能です。ほとんどのリクエストでは、ブラウザーを使用するだけで済みますが、リソース ヘッダーの実装では、テストに対してよりプログラム的なアプローチが必要です。ただし、すべての HTTP リクエスト (POST リクエストなど) が探索可能であるとは限らないため、PostmanやPawなどの Rest Client プラグインを使用する必要があります。 URI Pro/Header Con

  2. URI バージョンの API を使用すると、リソースの識別とリソースの表現が一緒に変更されます。これは REST の基本原則に違反しています。1 つのリソースは、1 つのエンドポイントのみによって識別される必要があります。この点で、リソース ヘッダーのバージョン管理の選択は、より学術的に理想的です。Header Pro/URI Con .

  3. URI でバージョン管理された API は、エラーが発生しにくく、クライアント開発者にとってよりなじみ深いものです。URL によるバージョン管理により、開発者はサービスのバージョンを一目で把握できます。クライアントの開発者がリソース バージョンをヘッダーに含めるのを忘れた場合、最新バージョン (バージョンをインクリメントするとエラーが発生する可能性があります) にリダイレクトするか、301 (Moved Permanatly) エラーにリダイレクトするかを決定する必要があります。いずれにせよ、初心者のクライアント開発者にとっては、より多くの混乱があります。URI Pro/Header Con
  4. URI のバージョン管理は、同じアプリケーションで複数のバージョンをホストするのに役立ちます。この場合、フレームワークをさらに開発する必要はありません。注: これを行うと、ディレクトリ構造の v2 ディレクトリにかなりの量の重複コードが含まれる可能性が高くなります。また、更新の展開にはシステムの再起動が必要です。したがって、この手法は可能な限り避ける必要があります。URI Pro/Header Con .
  5. 最初からバージョン管理をまだ考慮していなかった既存のプロジェクトの HTTP ヘッダーにバージョン管理を追加する方が簡単です。Header Pro/URI Con .
  6. RMM Level 3 REST Principle: Hypermedia Controlsに従って、HTTP Accept および Content-Type ヘッダーを使用して、データのバージョン管理とデータの記述を処理する必要があります。Header Pro/URI Con .
  7. バージョンを URL に入れると、クライアントは新しい API へのコード (または賢い場合は構成) の変更を調整する必要があります。Header Pro/URI Con .

さらに読みたい場合は、次のリンクが役立ちます。

于 2015-06-17T01:11:39.710 に答える