json - servicios - soap vs rest

¿Por qué usar XML(SOAP) cuando JSON es tan simple y fácil de manejar? (3)

Recibir y enviar datos con JSON se realiza con simples solicitudes HTTP. Mientras que en SOAP, tenemos que ocuparnos de muchas cosas. El análisis XML también es, a veces, difícil. Incluso Facebook usa JSON en Graph API. Todavía me pregunto por qué todavía se debe usar SOAP? ¿Hay alguna razón o área donde SOAP aún es una mejor opción? (A pesar del formato de datos)

Además, en aplicaciones simples de cliente-servidor (como aplicaciones móviles conectadas con un servidor), ¿puede SOAP dar alguna ventaja sobre JSON?

Estaré muy agradecido si alguien puede enlistar las diferencias principales / prominentes entre JSON y SOAP teniendo en cuenta la información que he proporcionado (si hay alguna).

Encontré lo siguiente sobre las ventajas de SOAP

Hay una gran razón por la que todos se quedan con SOAP en lugar de usar JSON. Con cada configuración de JSON, siempre se viene con su propia estructura de datos para cada proyecto. No me refiero a cómo se codifican y pasan los datos, sino cómo se define el formato con formato de datos, el modelo de datos.
SOAP tiene una manera madura de la industria de especificar que los datos estarán en la forma Cart es una colección de Productos y cada producto puede tener estos atributos, etc. Un documento WSDL bien elaborado realmente tiene esto clavado. Diablos, es una especificación W3C.
JSON tiene formas similares de especificar esta estructura de datos. Una clase de JavaScript viene a la mente como la forma más común de hacer esto. Una clase de JavaScript no es realmente una estructura de datos de ninguna manera agnóstica, bien establecida y ampliamente utilizada. Diablos, JavaScript realmente solo se ejecuta en un entorno, el navegador.
En resumen, SOAP tiene una forma de especificar la estructura de datos en un documento madurado con formato (WSDL). JSON no tiene una forma estándar de hacer esto.

Si está creando una aplicación cliente y su implementación de servidor está hecha con SOAP, entonces tiene que usar SOAP en el lado del cliente.

También mira here y here

Hoy en día SOAP es una exageración completa, en mi humilde opinión. Fue agradable usarlo, es bueno aprenderlo, y es hermoso que ahora podamos usar JSON.

La única diferencia entre los servicios SOAP y REST (sin importar si se usa JSON) es que SOAP WS siempre tiene su propio documento WSDL que podría transformarse fácilmente en una documentación autodescriptiva, mientras que dentro de REST debe escribir la documentación usted mismo (al menos para documentar las estructuras de datos). Aquí están mis contras y pros para ambos:

DESCANSO

Pros

liviano (en todos los sentidos: no se necesitan extensiones del servidor ni del lado del cliente, no se necesitan grandes porciones de XML para transferirlas aquí y allá)
Libre elección del formato de datos: depende de usted decidir si puede usar TXT, JSON, XML o incluso crear su propio formato de datos.
la mayoría de los formatos de datos actuales (e incluso si se usa XML) aseguran que solo la cantidad de datos realmente requerida se transfiere a través de HTTP, mientras que con SOAP para 5 bytes de datos se necesita 1 kB de XML basura (exagerado, ofc, pero se obtuvo el punto)

Contras

incluso si hay herramientas que podrían generar la documentación de los comentarios de docblock, es necesario escribir dichos comentarios de manera muy descriptiva si también se desea obtener una buena documentación

JABÓN

Pros

tiene un WSDL que podría generarse incluso desde comentarios docblock básicos (en muchos idiomas, incluso sin ellos) que funciona bien como una documentación
- incluso hay herramientas que podrían funcionar con WSDL para ofrecer una interfaz de solicitud mejorada (aunque no conozco ninguna herramienta de este tipo para REST)
estructura de datos estricta

Contras

estructura de datos estricta
utiliza un XML (¡solo!) para las transferencias de datos, mientras que cada solicitud contiene una gran cantidad de basura y la respuesta contiene cinco veces más basura de información
la necesidad de bibliotecas externas (para el cliente y / o el servidor, aunque hoy en día existen tales bibliotecas que son una parte nativa de muchos idiomas, sin embargo, la gente siempre tiende a usar algunas de terceros)

Para concluir, no veo una gran razón para preferir SOAP sobre REST (y JSON). Ambos pueden hacer lo mismo, hay soporte nativo para codificación y decodificación JSON en casi todos los lenguajes de programación web populares y con JSON usted tiene más libertad y las transferencias HTTP se limpian de gran cantidad de basura de información inútil. Si tuviera que construir cualquier API ahora, usaría REST con JSON.

No estoy de acuerdo con la tendencia de JSON que veo aquí. Aunque JSON es una orden de magnitud más fácil, me atrevería a decir que es bastante limitada. Por ejemplo, SOAP WS no es lo último. De hecho, entre soap client / server ahora tiene bus de servicios empresariales, esquema de autenticación basado en crypto, administración de usuarios, solicitudes / respuestas de marca de tiempo, etc. Por todo esto, hay algunas plataformas de software enormes que brindan servicios en torno a SOAP (bueno, "servicios web") e inyectará material en su XML. Entonces, aunque JSON probablemente sea suficiente para pequeños proyectos y un orden de magnitud más fácil allí, creo que se vuelve bastante limitado si se desacopla el control y el contenido de la transmisión (es decir, se desarrollan los contenidos, el servidor real, pero se administra toda la transmisión). por otro equipo, la autenticación de un equipo más, el despliegue de otro equipo). No sé si mi experiencia en un gran cuerpo es relevante, pero diría que JSON no sobrevivirá allí. Hay demasiadas restricciones además de la necesidad básica de representación de datos. Entonces, el problema no es JSON RPC, el problema es que se pierden las herramientas adicionales para administrar la complejidad que surge en aplicaciones complejas (por no decir que lo que se hace no es complejo, es solo que el software refleja la complejidad de la empresa que lo produce)