Donc, JSONP ou CORS?

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

Il semble que CORS soit beaucoup plus convivial pour le client et plus facile à mettre en œuvre .

Y a-t-il d’autres préoccupations que j’ai pu manquer?

Ceci est une question assez large, et pourrait justifier un wiki en soi. Il y a aussi un peu sur Google concernant les deux, mais je pense que je peux atteindre quelques points clés.

  • Si vous avez besoin d’une interface ajax en lecture seule sur vos serveurs et que vous devez prendre en charge IE < = 9, Opera <12 ou Firefox <3.5 ou d'autres navigateurs plus anciens ou plus anciens, CORS est désactivé, utilisez JSONP. IE8 et IE9 supportent CORS mais ont des problèmes, voir le lien dans le premier commentaire ci-dessous.
  • D’autre part, si votre API Web est en lecture / écriture (par exemple, REST complet ou simplement POST / GET) au lieu de simplement lire (c’est-à-dire GET), JSONP est désactivé. Utilisez CORS. JSONP est insortingnsèquement en lecture seule.

Si aucune de ces questions ne vous préoccupe, j’irais juste avec ce qui est le plus facile ou le plus familier pour vous. Si c’est un tossup, essayez CORS, car c’est la solution la plus “moderne” et JSONP est plus un hack, transformant les données en scripts pour contourner les ressortingctions entre domaines. Cependant, CORS nécessite généralement plus de configuration côté serveur.

Si vous utilisez jQuery, je ne sais pas où vous en êtes avec l’idée que CORS est « beaucoup plus convivial pour le client et plus facile à mettre en œuvre ». Voir https://gist.github.com/3131951 . jQuery résume les détails de JsonP, et CORS peut en fait être difficile à implémenter côté serveur en fonction de la technologie que vous utilisez.

J’ai récemment développé une application Web utilisant jquery et backbone.js, qui lit les différents services Web interdomaines que nous contrôlons, et a fini par utiliser Json-P au lieu de CORS car nous devons prendre en charge IE7 du côté serveur (nous exécutons Django avec DjangoRestFramework), et pratiquement le même avec jquery du côté client.

Vous êtes assez belle. Si vous n’avez pas à supporter les anciens navigateurs (ceux qui ont été lancés il y a plus de 6 ans), je serais certainement d’accord avec CORS.

CORS est plus facile à mettre en œuvre, car si votre API ne prend pas déjà en charge JSONP ou CORS, il est plus simple d’append quelques en-têtes statiques que de modifier le corps des réponses.

De plus, il est plus facile de mettre en cache les requêtes en utilisant CORS. Chaque requête JSONP doit être dynamic même avec du contenu mis en cache.

JSONP est toujours une balise de script, donc peu importe ce que cela causera un certain niveau de comportement synchrone. CORS ne le fera pas.

JSONP ne peut être qu’un GET. Et comme avec CORS, vous pouvez utiliser n’importe quelle méthode.

Last but not least, si vous utilisez jQuery v1.x , considérez que l’ error et les gestionnaires complete (ou mieux fail et always ) ne sont toujours pas appelés pour les requêtes JSONP dans certaines situations courantes (par exemple, erreurs réseau). Bien sûr, il existe des solutions de contournement (paramètre timeout, plug-in jQuery-JSONP), mais je trouve que CORS est moins ennuyeux, surtout lorsque les requêtes interdomaines ne proviennent que d’appareils mobiles (applications hybrides).

Selon la documentation de Spring, JSONP est un hack et non une solution appropriée de partage de ressources d’origine croisée. Donc, si la sécurité n’est pas votre problème, vérifiez simplement l’origine de votre domaine sur votre serveur et ajoutez l’en-tête Access-Control-Allow-Origin Response.

Notre API Web ne fonctionnait pas sur Safari (iOS 9.1) avec l’authentification Windows. Il travaillait avec Safari + iOS 8.4. Lorsque nous sums passés à JSONP, Safari a recommencé à fonctionner. Consultez ce lien pour plus d’informations.