REST APIをサブドメインまたはサブフォルダーに配置する方が良いですか？
URL http://example.comでホストされているWebアプリケーションがあります。次に、このアプリケーションの一部をRESTfulサービスとして拡張したいと考えています。現在、最適なURLパターンについて議論しています。調べてみたが具体的なガイダンスは見つからなかった。
URLパターンhttp://api.example.comまたはhttp://example.com/api/v1を使用する必要がありますか？
これに関する標準的なガイダンスはありますか？
それはあなたのニーズに依存します。
http://api.example.com を使用すると、APIがサブドメインになります。基本的に、このURLパターンは、RESTサービスが複数のクライアントによって使用される場合に適していますが、1つのクライアントのみがAPIに接続されている場合、パターン http：// example .com/api/v1 は良いですが、より多くのクライアントを接続してAPIを追加したい場合は、 http://example.com/api/v1 を使用することをお勧めします。たとえば、次のことを考慮してください。
http://example.com/reportapi/apioperation?parameters
http://example.com/paymentapi/apioperation?parameters
http://example.com/searchapi/apioperation?parameters
最後になりましたが、Paypalは http://example.com/api/v1 というパターンを使用します。
http://api.example.comもhttp://example.com/api/v1も使用しないことを検討してください。
代わりに、バージョン管理にhttp://example.com/apiとコンテンツネゴシエーションを使用することをお勧めします。
これが私の考えです。
サブドメインの使用：
RIスキーム仕様 に従って、ホストでアプリケーションまたは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 によるコンテンツタイプのバージョン管理について投稿してください。
これはトレードオフのケースであり、単一の最良のソリューションはありません。
たとえば、 http://example.com/ が標準のWebインターフェースおよびAPIを介してコンテンツを提供する場合、ブラウザベースを分離するだけでhttp://api.example.com/api/<version>/<the usual resource pattern>のようなものが必要ですAPIインタラクションからのアプリケーションアクセス。これは理にかなっていますか？
例：api.rottentomatoes.com
ただし、ドメインがAPI呼び出し専用である場合でも、上記のパターンを使用して、アプリケーションとやり取りする他の方法のために http://example.com/ を予約することは意味があります。たとえば、 http://example.com/mobile/ などが必要になる場合があります。