Api de Soap/Rest. Ha sido un problema desde hace un tiempo. y realmente, son solo dos respuestas a la misma pregunta: cómo acceder a la web servicios.
Pero decidir uno sobre el otro puede ser sorprendentemente difícil.
SOAP (Protocolo simple de acceso a objetos) es un protocolo web basado en estándares protocolo de acceso a servicios que existe desde hace mucho tiempo. Originalmente desarrollado por Microsoft, SOAP no es tan simple como el acrónimo sugeriría.
REST (Representational State Transfer) es otro estándar, hecho en respuesta a las deficiencias de SOAP. Busca arreglar los problemas con SOAP y proporcionar un método más simple para acceder a los servicios web.
¿Qué pasa con GraphQL?
Por supuesto, GraphQL recientemente causó un gran revuelo, del cual hemos hablado
de extenso en otros artículos. Pero todavía no está tan estandarizado como
REST y SOAP, por lo que en este artículo solo nos centraremos en esos
dos.
Tanto SOAP como REST tienen problemas a considerar al decidir qué protocolo usar.
Las similitudes
Si bien SOAP y REST comparten similitudes sobre el protocolo HTTP, SOAP
es un conjunto de patrones de mensajería más rígido que REST. Las reglas en SOAP
son importantes porque no podemos lograr ningún nivel de estandarización
sin ellas. REST como estilo de arquitectura no requiere procesamiento
y es naturalmente más flexible. Tanto SOAP como REST se basan en
reglas bien establecidas que todos han acordado cumplir en el
interés de intercambiar información.
Una descripción general rápida de SOAP
SOAP se basa exclusivamente en XML para proporcionar servicios de mensajería. Microsoft desarrolló originalmente SOAP para reemplazar a los antiguos tecnologías que no funcionan bien en Internet, como el Modelo de objetos de componentes distribuidos (DCOM) y solicitud de objetos comunes Broker Arquitectura (CORBA). Estas tecnologías fallan porque dependen en mensajería binaria. La mensajería XML que emplea SOAP funciona mejor a través de Internet.
Después de un lanzamiento inicial, Microsoft envió SOAP a Internet Engineering Task Force (IETF) donde se estandarizó. jabón es diseñado para admitir la expansión, por lo que tiene todo tipo de otros acrónimos y abreviaturas asociadas con él, como WS-Addressing, WS-Policy, WS-Security, WS-Federation, WS-ReliableMessaging, WS-Coordination, WS-AtomicTransaction y WS-RemotePortlets. De hecho, puedes encontrar un lista completa de estos estándares en Estándares de servicios web.
El punto es que SOAP es altamente extensible, pero solo usa el
piezas que necesita para una tarea en particular. Por ejemplo, cuando se utiliza un público
servicio web que está disponible gratuitamente para todos, realmente no tienes
mucha necesidad de WS-Security.
La dificultad depende del lenguaje de programación
El XML utilizado para realizar solicitudes y recibir respuestas en SOAP puede convertirse
extremadamente complejo. En algunos lenguajes de programación, necesita construir
esas solicitudes manualmente, lo que se vuelve problemático porque SOAP es
intolerante a los errores. Sin embargo, otros idiomas pueden usar atajos que
proporciona SOAP. Pueden ayudarlo a reducir el esfuerzo requerido para crear
la solicitud y analizar la respuesta. De hecho, cuando se trabaja con .NET
idiomas, ni siquiera ves el XML.
Parte de la magia es el lenguaje de descripción de servicios web (WSDL).
Este es otro archivo asociado con SOAP. Proporciona un
definición de cómo funciona el servicio web, de modo que cuando crea un
referencia a él, el IDE puede automatizar completamente el proceso. Entonces el
La dificultad de usar SOAP depende en gran medida del idioma que utilice.
usar.
Gestión de errores integrada
Una de las características más importantes de SOAP es el manejo de errores incorporado. Si
hay un problema con su solicitud, la respuesta contiene error
información que puede utilizar para solucionar el problema. Dado que podrías
no posee el servicio web, esta característica en particular es extremadamente importante;
de lo contrario, se quedaría adivinando por qué las cosas no funcionaron. Él
el informe de errores incluso proporciona códigos estandarizados para que sea posible
para automatizar algunas tareas de manejo de errores en su código.
Una característica interesante de SOAP es que no necesariamente tiene que usarla con el transporte HTTP . Hay una especificación real para usar SOAP sobre el Protocolo simple de transferencia de correo (SMTP) y no hay ninguna razón por la que no pueda usarlo sobre otros transportes De hecho, los desarrolladores en algunos lenguajes, como Python y PHP, están haciendo precisamente eso.
Formulario de solicitud