jsonp - mvc - net core api cors

Entonces, ¿JSONP o CORS?

Question

Mi WebAPI se implementó en el entorno de Intranet . Eso significa que la seguridad no era mi problema.

Parece que CORS es mucho más amigable para el cliente y más fácil de implementar .

¿Alguna otra preocupación que podría haber perdido?

Answer 1

Eres bastante acertado. Si no tiene que admitir navegadores heredados (los lanzados hace más de 6 años), definitivamente iría con CORS.

CORS es más fácil de implementar, ya que si su API no admite JSONP o CORS, es más fácil agregar solo algunos encabezados estáticos que modificar el cuerpo de respuestas.

También es más fácil guardar en caché las solicitudes usando CORS. Cada solicitud JSONP debe ser dinámica incluso con contenido protegido.

JSONP sigue siendo una etiqueta de script, por lo que no importa lo que cause un cierto nivel de comportamiento sincrónico. CORS no lo hará.

JSONP solo puede ser un GET. Y al igual que con CORS puedes usar cualquier método.

Answer 2

Esta es una pregunta bastante amplia, y podría justificar una wiki en sí misma. También hay un poco en google con respecto a los dos, pero creo que puedo golpear algunos puntos clave.

• Si necesita una interfaz ajax de solo lectura para sus servidores y necesita soportar IE <= 9, Opera <12 o Firefox <3.5 u otros navegadores antiguos u oscuros, CORS está fuera, use JSONP. IE8 e IE9 soportan CORS pero tienen problemas, vea el enlace en el primer comentario a continuación.
• Por otro lado, si su API web es de lectura / escritura (por ejemplo, REST completo o simplemente POST / GET) en lugar de simplemente leer (es decir, GET), JSONP está desactivado. Usa CORS. JSONP es intrínsecamente de solo lectura.

Si ninguno de estos es una preocupación, simplemente iré con lo que sea más fácil o más familiar para usted. Si es un lanzamiento, prueba CORS, ya que es la solución más "moderna" y JSONP es más un hack, convirtiendo datos en scripts para eludir las restricciones entre dominios. Sin embargo, CORS generalmente requiere más configuración del lado del servidor.

Si está utilizando jQuery, no estoy seguro de dónde se le ocurre la idea de que CORS sea " mucho más amigable para el cliente y más fácil de implementar ". Ver https://gist.github.com/3131951 . jQuery abstrae los detalles de JsonP, y CORS en realidad puede ser un tanto complicado de implementar en su servidor dependiendo de la tecnología que esté usando.

Recientemente desarrollé una aplicación web, usando jquery y backbone.js, que lee de varios servicios web de dominio cruzado que controlamos, y terminamos usando Json-P en lugar de CORS porque necesitamos dar soporte a IE7 y fue un poco más simple en el lado del servidor (ejecutamos Django w / DjangoRestFramework), y prácticamente lo mismo con jquery en el lado del cliente.

Answer 3

Nuestra API web no funcionaba en Safari (iOS 9.1) con Autenticación de Windows. Estaba trabajando con Safari + iOS 8.4. Cuando cambiamos a JSONP Safari comenzó a funcionar nuevamente. Verifique este enlace para más información.

Answer 4

Según Spring Documentation, JSONP es un truco y no una solución adecuada de Cross Origin Resource Sharing. Entonces, si la seguridad no es su problema, simplemente verifique el origen de su dominio en su servidor y agregue el encabezado Respuesta-Control-Permitir-Origen-Respuesta.

Answer 5

Por último, pero no menos importante, si está utilizando jQuery v1.x , considere que los controladores de error y complete (o mejor, fail y always ) aún no reciben solicitudes de JSONP en algunas situaciones comunes (por ejemplo, errores de red). Claro que hay soluciones temporales (configuración de tiempo de espera, plugin jQuery-JSONP), pero considero que CORS es menos molesto, especialmente cuando las solicitudes de dominio cruzado solo provienen de dispositivos móviles (es decir, aplicaciones híbridas) por lo que no necesita soporte para buscadores desafortunados.