http://api.example.com
どちらも使用しないことを検討する必要があると思いますhttp://example.com/api/v1
。
代わりにhttp://example.com/api
、バージョン管理にコンテンツ ネゴシエーションを使用することをお勧めします。
理由は次のとおりです。
サブドメインの使用:
URIスキーム仕様に従って、ホストでアプリケーションまたは API を定義するのではなく、ホストを定義するために使用される URI の機関部分で API を定義しています。実際には、API 用に別のアドレスを作成しています。つまり、example.com の場合とは異なり、api.example.com では認証が機能しない可能性があります。
これを行う正当な理由は、mobile.example.com などのモバイル デバイス用の新しいインスタンスを設計するときかもしれませんが、これは機能上の決定ではなく、インフラストラクチャ上の決定と見なします。
メイン ドメインでバージョン管理されていないパスを使用する:
ここには 2 ビットの情報があります。1 つは API リソースがあることを示し、2 つ目はその API リソースのバージョン番号 (v1) があることを示します。
/api/
API と、たとえば で実行される Web ビューを区別するためにを使用することは悪いことではありません/web/
。これは、一般的なベスト プラクティスと見なすことができます。
あなたがこれを意図したかどうかはわかりませんが、あなたの質問には、API のバージョン管理を解決する方法に関するクエリが含まれています。個人的には、API のバージョン管理は URL を使用して行うべきではないと考えています。URL は可能な限り安定した状態を維持することを目的としているためです。クールな URI は変わりません! 代わりに、HTTP Content-Type 情報を使用して API をバージョン管理することを検討してください。実際、この方法はVMware のドキュメントで使用されていることがわかりました。さらに、 Peter Williamsによるコンテンツ タイプのバージョン管理に関する非常に古い投稿ですが、今でも有用です。