JSONPかCORSか？
WebAPIがイントラネット環境にデプロイされました。つまり、セキュリティは私の懸念ではありませんでした。
CORSは、クライアントにとってはるかに友好的であり、実装が容易であるようです。
私が逃したかもしれない他の懸念はありますか？
これはかなり広範な質問であり、Wiki自体を保証することができます。 2つに関してはgoogleにもかなりの部分がありますが、いくつかの重要なポイントを見つけることができると思います。
- サーバーへの読み取り専用ajaxインターフェースが必要で、IE <= 9、Opera <12、Firefox <3.5、またはその他のさまざまな古いブラウザーまたはあいまいなブラウザーをサポートする必要がある場合、CORSは使用できません。JSONPを使用してください。 IE8およびIE9は、CORSをサポートしていますが、問題があります。以下の最初のコメントのリンクを参照してください。
- 一方、Web APIが読み取り/書き込み（たとえば、完全なRESTまたは単にPOST/GET）である場合、読み取り（GET）ではなく、JSONPは出力されます。CORSを使用してください。 JSONPは本質的に読み取り専用です。
これらのどちらも懸念事項ではない場合、私はあなたにとって最も簡単なまたは最も馴染みのあるものだけで行きます。それがトッサップの場合、CORSを試してみてください。これはより「現代的な」ソリューションであり、JSONPはハッキングのようなもので、データをスクリプトに変換してクロスドメインの制限を回避します。ただし、CORSでは通常、より多くのサーバー側の構成が必要です。
JQueryを使用している場合、CORSがクライアントにとって「はるかに友好的」であり、「実装しやすい」であるという考えをどこで考えているのかわかりません。 」 https://Gist.github.com/3131951 を参照してください。 jQueryはJsonPの詳細を抽象化するため、使用しているテクノロジーによっては、CORSが実際にサーバー側に実装するのが多少難しい場合があります。
私は最近、jqueryとbackbone.jsを使用してWebアプリを開発しました。これは私たちが制御するさまざまなクロスドメインWebサービスから読み取り、IE7をサポートする必要があるため、CORSの代わりにJson-Pを使用することになりましたサーバー側（Django w/DjangoRestFramework）を実行します。クライアント側のjqueryとほぼ同じです。
あなたはかなりスポットです。レガシーブラウザ（6年以上前にリリースされたブラウザ）をサポートする必要がない場合は、間違いなくCORSを使用します。
APIがJSONPまたはCORSをまだサポートしていない場合、応答の本文を変更するよりもいくつかの静的ヘッダーを追加する方が簡単であるため、CORSの実装は簡単です。
また、CORSを使用してリクエストをキャッシュするのも簡単です。各JSONPリクエストは、memcachedコンテンツでも動的である必要があります。
JSONPは依然としてスクリプトタグであるため、それが何らかのレベルの同期動作を引き起こすかどうかは関係ありません。 CORSはしません。
JSONPはGETのみです。また、CORSと同様に、任意の方法を使用できます。
最後になりましたが、jQuery v1.xを使用している場合は、errorとcomplete（またはより良いfailとalways）ハンドラーは、いくつかの一般的な状況（ネットワークエラーなど）でJSONPリクエストに対して呼び出されません。回避策（タイムアウト設定、jQuery-JSONPプラグイン）がありますが、CORSは面倒ではなく、特にクロスドメインリクエストがモバイルデバイス（つまり、ハイブリッドアプリ）からのみ送信される場合は、不運なブラウザーをサポートする必要はありません。
Spring Documentationによると、JSONPはハックであり、クロスオリジンリソース共有の適切なソリューションではありません。したがって、セキュリティが問題にならない場合は、サーバー上のドメインオリジンを確認し、Access-Control-Allow-Origin Responseヘッダーを追加するだけです。