Alors, JSONP ou CORS ?

Question

Mon WebAPI a été déployé au sein de l’Intranet . Cela signifie que la sécurité n’était pas ma préoccupation.

Il semble que la SCRO est beaucoup plus convivial pour le client et le plus facile à implémenter.

Pour toute autre question, que j’aurais raté ?

Answer 1

C'est une question assez vaste question, et pourrait justifier un wiki en lui-même. Il y a aussi un peu sur google concernant les deux, mais je pense que je peux frapper quelques points clés.

• Si vous avez besoin de soutien IE<=7, Opera<12, ou Firefox<3.5 ou divers autres plus ou obscurs navigateurs, de la SCRO, utilisez JSONP.
• D'autre part, si votre site web API est en lecture/écriture (par exemple, le plein REPOS ou simplement de POST/GET) au lieu de simplement le lire (c'est à dire SE), vous allez passer un mauvais moment avec l'JSONP, l'utilisation de la SCRO.

Si aucune de ces sont un sujet de préoccupation, et la sécurité n'est pas un sujet de préoccupation. Je voudrais juste aller avec ce qui est le plus facile ou le plus familier pour vous. Si ses un tossup, essayez de la SCRO, puisque ça semble être la plus "moderne" de la solution.

Si vous utilisez jQuery, je ne suis pas sûr de l'endroit où vous êtes à venir avec l'idée que la SCRO est "beaucoup plus facile pour le client et plus facile à mettre en œuvre." Voir https://gist.github.com/3131951 . jQuery résumés les détails de JsonP, et de la SCRO peut effectivement être un peu difficile de implment sur votre côté serveur en fonction de ce que la technologie que vous utilisez.

J'ai récemment développé une application web, à l'aide de jquery et backbone.js qui lit à partir de différentes croix-domaine des services web que nous avons le contrôle, et s'est terminé vers le haut en utilisant Json-P au lieu de la SCRO, car nous avons besoin de soutien IE7 et il était un peu plus simple sur le côté serveur (nous courons Django w/ DjangoRestFramework), et pratiquement la même chose avec jquery sur le côté client.

Answer 2

Vous êtes assez tache sur. Si vous n'avez pas à soutenir les anciens navigateurs (ceux libérés de 6 ans), je voudrais certainement aller avec la SCRO.

La SCRO est plus facile à mettre en œuvre, dans la mesure où si votre API n'est pas déjà le soutien JSONP ou de la SCRO il est plus facile de simplement ajouter un peu de statique des en-têtes de modifier le corps de réponses.

Aussi, il est plus facile pour mettre en cache les requêtes à l'aide de la SCRO. Chaque JSONP demande doit être dynamique, même avec memcached de contenu.

JSONP est toujours une balise de script, donc, peu importe ce qu'il fera quelques niveau de comportement synchrone. La SCRO ne sera pas.

JSONP ne peut être un GET. Et comme avec la SCRO vous pouvez utiliser n'importe quel méthode.

Answer 3

Dernière mais pas moins, si vous êtes à l'aide de jQuery v1.x, considèrent qu' error et complete (ou mieux, fail et always) des gestionnaires ne sont pas encore appelé pour JSONP demandes dans certaines situations courantes (par exemple, des erreurs de réseau). Bien sûr il ya des solutions de contournement (paramètre de délai d'attente, jQuery-JSONP plugin), mais je trouve que C moins gênant, particulièrement lorsque des requêtes inter-domaine ne sont à venir à partir d'appareils mobiles (i.e. les applications hybrides), de sorte que vous n'avez pas besoin de support pour les malchanceux navigateurs.