26

RESTful API を作成する予定ですが、バージョン管理の方法がわかりません。私は多くの議論やブログ記事を読み、バージョン管理に Accept ヘッダーを使用することを提案しています。

しかし、その後、一般的な REST API とそのバージョン管理方法をリッスンしている次の Web サイトを見つけました。それらのほとんどは、バージョン管理に URL を使用しています。なんで？

ほとんどの人が「URL を使用せず、accept ヘッダーを使用する」と言っているのに、URL を使用する一般的な API はなぜですか?

4

1 に答える 1

34

どちらのメカニズムも有効です。従うべき道を知るには、消費者を知る必要があります。一般に、企業や学問に関心のある人々と協力する場合、開発者はリソース ヘッダーのバージョン管理を行う傾向があります。ただし、クライアントが中小企業の場合は、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 .

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

于 2015-06-17T01:15:07.823 に答える