Alors, JSONP ou CORS? [fermé]


111

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'aurais pu manquer?

Réponses:


144

C'est une question assez large, et pourrait justifier un wiki en soi. Il y a aussi pas mal de choses sur Google concernant les deux, mais je pense que je peux aborder quelques points clés.

  • Si vous avez besoin d'une interface ajax en lecture seule pour vos serveurs et que vous devez prendre en charge IE <= 9, Opera <12 ou Firefox <3.5 ou divers autres navigateurs plus anciens ou obscurs, CORS est sorti, utilisez JSONP. IE8 et IE9 prennent en charge 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 sorti. Utilisez CORS. JSONP est intrinsèquement en lecture seule.

Si aucun de ces problèmes ne vous inquiète, je choisirais simplement ce qui vous est le plus simple ou le plus familier. 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 restrictions interdomaines. Cependant, CORS nécessite généralement plus de configuration côté serveur.

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

J'ai récemment développé une application Web, en utilisant jquery et backbone.js, qui lit à partir de divers services Web interdomaines que nous contrôlons, et j'ai fini par utiliser Json-P au lieu de CORS car nous devons prendre en charge IE7 et c'était un peu plus simple sur côté serveur (nous exécutons Django avec DjangoRestFramework), et pratiquement la même chose avec jquery côté client.


3
Si vous supportez IE8 et IE9, il peut également exclure CORS car le Content-Type est forcé à "text / plain", voir le point (4) sur blogs.msdn.com/b/ieinternals/archive/2010/05 / 13 /…
jamiebarrow

L'essentiel de votre réponse est très utile, merci!
MVCDS

Ce que j'ai compris, c'est que JSONP que vous devez gérer côté client et CORS que vous devez gérer côté serveur. correct?
Dips

Je veux juste ajouter que même jsonp peut être appelé via GET, vous pouvez coder votre backend pour effectuer des écritures. Vous pouvez passer des paramètres sur la chaîne de requête, de sorte que vous puissiez simuler les paramètres post, put, patch avec un paramètre GET et quesystring. (pas l'idéal bien sûr)
Gabriel Carignano

45

Vous êtes assez sur place. Si vous n'avez pas à prendre en charge les anciens navigateurs (ceux sortis il y a plus de 6 ans), j'irais certainement avec CORS.

CORS est plus facile à implémenter, en ce sens que si votre API ne prend pas déjà en charge JSONP ou CORS, il est plus facile d'ajouter simplement quelques en-têtes statiques que de modifier le corps des réponses.

Il est également plus facile de mettre en cache les requêtes à l'aide de CORS. Chaque demande JSONP doit être dynamique même avec du contenu memcached.

JSONP est toujours une balise de script, donc peu importe ce qu'il provoquera 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.


3
J'ai apprécié les informations sur le "comportement synchrone".
Juan Lanus

Je crois que vous pouvez faire un téléchargement de script de manière asynchrone. JQuery fournit ce paramètre sur ses requêtes ajax. Je ne sais pas si cela fonctionne pour jsonp ou non. api.jquery.com/jquery.ajax
eran otzap

11

Enfin, si vous utilisez jQuery v1.x , considérez que les gestionnaires erroret complete(ou mieux failet always) ne sont toujours pas appelés pour les requêtes JSONP dans certaines situations courantes (par exemple, les erreurs réseau). Bien sûr, il existe des solutions de contournement (paramètre de délai d'expiration, plugin jQuery-JSONP), mais je trouve CORS moins ennuyeux, en particulier lorsque les demandes inter-domaines proviennent uniquement d'appareils mobiles (c'est-à-dire d'applications hybrides), vous n'avez donc pas besoin de support pour les navigateurs malchanceux.


1
+1 pour les informations sur les rappels
plainjimbo

1

Selon Spring Documentation, JSONP est un hack et non une solution appropriée de partage de ressources Cross Origin. Donc, si la sécurité n'est pas votre préoccupation, vérifiez simplement l'origine de votre domaine sur votre serveur et ajoutez l'en-tête de réponse Access-Control-Allow-Origin.


-1

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


C'est aussi un bon article - blog.algolia.com/jsonp-still-mandatory
Anoop
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.