私の WebAPI はイントラネット環境にデプロイされました。つまり、セキュリティは私の関心事ではありませんでした。
CORS はクライアントにとってはるかに使いやすく、実装が容易なようです。
私が見逃したかもしれない他の懸念はありますか?
私の WebAPI はイントラネット環境にデプロイされました。つまり、セキュリティは私の関心事ではありませんでした。
CORS はクライアントにとってはるかに使いやすく、実装が容易なようです。
私が見逃したかもしれない他の懸念はありますか?
これは非常に幅広い質問であり、ウィキ自体を正当化する可能性があります。この 2 つに関しては、Google にもかなりの情報がありますが、いくつかの重要なポイントを見つけることができると思います。
これらのどちらも問題にならない場合は、あなたにとって最も簡単または最も馴染みのあるものを使用します. CORS はより「最新の」ソリューションであり、JSONP はハックに近いため、データをスクリプトに変換してクロスドメインの制限を回避するためです。ただし、CORS は通常、より多くのサーバー側の構成を必要とします。
jQuery を使用している場合、CORS が「クライアントにとってはるかに使いやすく、実装しやすい」という考えをどこから思いついたのかわかりません。https://gist.github.com/3131951を参照してください。jQuery は JsonP の詳細を抽象化します。CORS は、使用しているテクノロジによっては、実際にはサーバー側に実装するのがやや難しい場合があります。
私は最近、jquery と backbone.js を使用して、私たちが制御するさまざまなクロスドメイン Web サービスから読み取る Web アプリを開発し、IE7 をサポートする必要があり、少し簡単だったため、CORS の代わりに Json-P を使用することになりました。サーバー側 (DjangoRestFramework を使用して Django を実行)、およびクライアント側の jquery と実質的に同じです。
あなたはかなりスポットです。レガシ ブラウザー (6 年以上前にリリースされたもの) をサポートする必要がない場合は、間違いなく CORS を使用します。
API がまだ JSONP または CORS をサポートしていない場合は、応答の本文を変更するよりも、いくつかの静的ヘッダーを追加する方が簡単であるという点で、CORS は実装が簡単です。
また、CORS を使用してリクエストをキャッシュする方が簡単です。memcached コンテンツであっても、各 JSONP リクエストは動的である必要があります。
JSONP は依然としてスクリプト タグであるため、何らかのレベルの同期動作が発生することはありません。CORS はそうしません。
JSONP は GET のみです。CORS と同様に、任意の方法を使用できます。
Spring Documentation によると、JSONP はハックであり、Cross Origin Resource Sharing の適切なソリューションではありません。したがって、セキュリティが問題ではない場合は、サーバーでドメインのオリジンを確認し、Access-Control-Allow-Origin Response ヘッダーを追加してください。
Web API は、Windows 認証を使用する Safari (iOS 9.1) では機能しませんでした。Safari + iOS 8.4 で動作していました。JSONP Safari に変更すると、再び動作するようになりました。詳細については、このリンクを確認してください。