Alors, JSONP ou CORS?
Mon WebAPI a été déployé dans l'environnement Intranet. Cela signifie que sécurité n'était pas ma préoccupation.
Il semble que CORS est beaucoup plus convivial pour le client et plus facile à mettre en œuvre.
Avez-vous manqué d'autres préoccupations?
C'est une question assez large, et pourrait justifier un wiki en soi. Il y a aussi pas mal de choses sur Google dans les deux cas, mais je pense pouvoir toucher quelques points clés.
- Si vous avez besoin d'une interface ajax en lecture seule avec vos serveurs et que vous devez prendre en charge IE <= 9, Opera <12, ou Firefox <3.5 ou divers autres navigateurs plus anciens ou plus 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.
- Par contre, si votre API Web est en lecture/écriture (par exemple, full REST ou simplement POST/GET) au lieu de simplement en lecture (par exemple, GET), JSONP est désactivé. Utilisez CORS. JSONP est par nature en lecture seule.
Si aucun de ces problèmes ne vous préoccupe, je choisirais simplement ce qui vous est le plus facile ou le plus familier. Si c'est un tossup, essayez CORS, puisqu'il s'agit de la solution la plus "moderne" et que JSONP est plus un piratage informatique, transformant les données en scripts pour contourner les restrictions entre domaines. Cependant, CORS nécessite généralement davantage de configuration côté serveur.
Si vous utilisez jQuery, je ne sais pas trop où vous pensez 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 réalité être difficile à mettre en œuvre sur votre serveur, en fonction de la technologie utilisée.
J'ai récemment développé une application Web, 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. côté serveur (nous exécutons Django avec DjangoRestFramework), et pratiquement la même chose avec jquery du côté client.
Vous êtes joli sur place. Si vous n'avez pas à supporter les anciens navigateurs (ceux qui ont été publiés il y a plus de 6 ans), j'adopterais certainement CORS.
CORS est plus facile à mettre en œuvre. En effet, si votre API ne prend pas déjà en charge JSONP ou CORS, il est plus simple d'ajouter quelques en-têtes statiques que de modifier le corps des réponses.
En outre, il est plus facile de mettre en cache les demandes à l'aide de CORS. Chaque demande JSONP doit être dynamique, même avec du contenu memcached.
JSONP est toujours une balise de script. Par conséquent, peu importe le type de comportement synchrone. La SCRO ne le fera pas.
JSONP ne peut être qu'un GET. Et comme avec CORS, vous pouvez utiliser n’importe quelle méthode.
Enfin, si vous utilisez jQuery v1.x, considérez que error et complete (ou mieux fail et always) les gestionnaires ne sont toujours pas appelés pour les requêtes JSONP dans certaines situations courantes (erreurs de réseau, par exemple). Il existe certes des solutions (paramètre de délai d’expiration, plug-in jQuery-JSONP), mais je trouve CORS moins ennuyeux, en particulier lorsque les demandes interdomaines ne proviennent que de périphériques mobiles (applications hybrides), de sorte que vous n’avez pas besoin de l'assistance de navigateurs malchanceux.
Selon Spring Documentation, JSONP est un hack et non une solution appropriée du partage de ressources d'origine croisée. Donc, si la sécurité ne vous concerne pas, vérifiez simplement votre domaine Origin sur votre serveur et ajoutez un en-tête de réponse Access-Control-Allow-Origin.