54

ドメイン名が。のWebアプリケーションがありますexample.com。ここで、このアプリケーションの一部をREST APIとして拡張したいと考えており、最適なURLパターンについて議論しています。

URLパターンapi.example.comまたはを使用できますexample.com/api。もしあれば、どのようなトレードオフを考慮する必要がありますか?

さらに、APIバージョニングの方法に関してどのようなトレードオフがありますか?v1.api.example.comこれは、URL( 、、、またはexample.com/api/v1奇妙な組み合わせv1.example.com/apiまたは)を介して実行できますapi.example.com/v1。または、HTTPリクエストヘッダー(またはその他)を使用して実行することもできますか?

4

3 に答える 3

20

それはあなたのニーズに依存します。

http://api.example.comを使用すると、API がサブドメインになります。基本的に、REST サービスが複数のクライアントによって使用される場合は、この URL パターンが適していますが、API に接続されているクライアントが 1 つだけの場合は、パターン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を使用します。

于 2013-01-28T03:28:50.787 に答える
5

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によるコンテンツ タイプのバージョン管理に関する非常に古い投稿ですが、今でも有用です。

于 2013-10-06T13:42:59.043 に答える
-1

これはトレードオフのケースであり、最適なソリューションは 1 つではありません。

たとえば、http://example.com/が API だけでなく標準の Web インターフェイスを介してコンテンツを提供する場合、http://api.example.com/api/<version>/<the usual resource pattern> ブラウザベースのアプリケーション アクセスと API のやり取りを分離するだけのようなものが必要です。これは理にかなっていますか?

例: api.rottentomatoes.com

ただし、ドメインが API 呼び出し専用であっても、いずれにせよ上記のパターンを使用し、アプリケーションと対話する他の方法のためにhttp://example.com/を予約することは意味があります。たとえば、http://example.com/mobile/などが必要になる場合があります。

于 2013-01-28T06:23:13.670 に答える