Como he dicho en muchos de los artículos, uno de los objetivos de este blog es aprender y enseñar lo que sé dentro del mundo SAP y de tecnología en general. En este caso vamos a ir a algo básico, pero no con ello conocido por todos. Es probable que haya mucha gente que ya sepa de lo que estoy hablando, pero seguro que hay algunos que les viene bien para sentar las bases. Vamos a hablar de:
¿Qué es un Servicio Web?
Los servicios web son aplicaciones que se comunican y comparten datos e información a través de la red, utilizando un conjunto de estándares y protocolos abiertos. Están diseñados para soportar la interacción máquina a máquina, facilitando la interoperabilidad entre sistemas heterogéneos. Es decir, dos sistemas no necesitan conocerse para poder comunicarse mientras se acojan a las reglas de comunicación del estándar de servicio web usado. Puedes conectar un SAP con Java, Python, etc. Y cualquier tecnología que sepa manejar los Servicios web.
Vamos a verlo con una analogía. Por ejemplo la telefonía. Existen terminales con distintas tecnologías, fijos, fax, Android, IOS, etc. Pero todos pueden conectarse a la red y hacer y recibir llamadas, mensajes y datos. Cada tecnología usa un estándar de comunicación y, cuando haces una llamada no andas pensando si el que recibe la llamada es Android, IOS o fijo.
Sistemas como Cajas Negras
Y para conseguir entenderlo del todo e intentar bajar a tierra el concepto, podemos simplificarlo viendo a los sistemas como Cajas Negras.
Imagina que cada sistema o aplicación es como una casa grande y compleja, llena de diferentes habitaciones. Cada habitación contiene algo valioso: información, herramientas, o incluso formas de interactuar con el mundo exterior. Pero para acceder a estos tesoros, necesitas entrar por la puerta correcta.
Los servicios web son como estas puertas. Cada puerta está diseñada para un propósito específico: algunas te permiten ver lo que hay dentro (consultar datos), otras te permiten cambiar algo (modificar datos), otras te permiten agregar cosas nuevas (introducir nuevos datos) o incluso eliminar algo existente.
Cuando usas un servicio web, es como si tuvieras la llave correcta para abrir una de estas puertas. Lo interesante es que estas puertas pueden estar en cualquier parte del mundo. No importa dónde estés, si tienes la llave correcta (en este caso, el acceso al servicio web adecuado y la forma de llamarlo), puedes abrir la puerta y hacer lo que necesites hacer.
Por ejemplo, cuando usas una aplicación en tu teléfono para consultar el clima, estás utilizando un servicio web para «abrir la puerta» de un sistema que te proporciona información meteorológica actualizada. O cuando haces un pedido en línea, estás usando otro servicio web para «abrir la puerta» de un sistema de comercio electrónico, permitiéndote agregar productos a tu carrito y realizar una compra.
Ejemplo «Real»
Imagínate que tienes un sistema SAP de gestión comercial y de creación con clientes (CRM) y quieres que cualquier sistema que ‘capte’ posibles futuros clientes, cree una ficha de datos y un documento para que un comercial le contacte. Por ejemplo, una persona da sus datos en una web o cuando una persona se da de alta en otra empresa del grupo pero cede sus datos para fines comerciales.
En SAP podemos crear un servicio web que permita recibir:
- Nombre
- Apellidos
- Telefono
- Id externo
Cuando el servicio web reciba esta información, internamente, ya en SAP, creará el BP y el documento de seguimiento. Y el servicio devolverá:
- Id BP SAP
- Id Documento Seguimiento
¿Qué sistemas llamarán a este Servicio Web? Pues cualquiera que:
- Tenga acceso a la Máquina de SAP (por Red, firewall y Autenticación)
- Sepa llamar al servicio
En este caso la web y el sistema que gestione la otra empresa. ¿Qué tecnologías son? Da igual, ¿es HTML? ¿PHP? ¿Java? ¿SAP? ¿. NET? Da lo mismo, mientras que sepa como llamar y tenga visibilidad. Y quienes quieran llamar en un futuro claro.
Tipos de Web Service
Existen varios tipos de servicios web, pero los más comunes son:
SOAP (Simple Object Access Protocol)
SOAP es un protocolo estándar que permite la comunicación entre aplicaciones a través de redes, utilizando XML para codificar los mensajes.
Archivo WSDL (Web Services Description Language)
Los servicios SOAP cuentan con un archivo de definición del servicio en formato XML que el sistema que lo crea lo genera y se lo entrega a cualquier sistema que quiera usarlo. En ese documento está definido todas las acciones, estructuras de mensajes entrada / salida y los tipos de datos de cada campo. De esa forma, cualquier sistema que quiera usar ese servicio web no necesita conocer el sistema destino, solamente debe saber generar y recibir ficheros XML en base a las especificaciones del WSDL.
Seguridad en SOAP
A nivel de seguridad tenemos muchas opciones o capas de seguridad para el uso de los servicios web SOAP:
- WS-Security: es una extensión de SOAP para abordar la seguridad en la comunicación de servicios web. Permite Autenticación mediante tokens de seguridad como contraseñas, tokens SAML, y certificados X.509.
- SSL/TLS: Aunque no es específico de SOAP, el uso de SSL (Secure Socket Layer) o TLS (Transport Layer Security) añade una capa adicional de seguridad al encapsular la comunicación SOAP en un canal seguro.
REST (Representational State Transfer)
REST no es un protocolo sino un conjunto de principios arquitectónicos para diseñar servicios web. REST utiliza métodos HTTP como GET, POST, PUT y DELETE para operaciones CRUD (Crear, Leer, Actualizar, Eliminar), lo que lo hace intuitivo y fácil de usar. Los datos y la funcionalidad se consideran «recursos» y se accede a ellos a través de URIs (Uniform Resource Identifiers).
El formato de intercambio más habitual es mediante JSON (JavaScript Object Notation) que es un formato ligero de intercambio de datos. Es fácil de leer y escribir para humanos, y fácil de analizar y generar para máquinas. Aunque también puede usar XML, HTML O texto plano.
Ventajas de REST
- Eficiencia y Escalabilidad: REST permite manejar un gran número de solicitudes simultáneamente, lo que lo hace muy escalable.
- Facilidad de Uso: Al usar estándares HTTP, es fácil de entender y utilizar para los desarrolladores.
- Flexibilidad: Permite el uso de múltiples formatos de datos como JSON, XML, texto plano, etc., lo que lo hace versátil.
Desventajas
- Seguridad: La seguridad en REST debe ser manejada cuidadosamente, ya que no proporciona estándares de seguridad integrados como SOAP.
- Limitaciones en Solicitudes Complejas: Para operaciones que requieren un procesamiento más complejo o transacciones, REST puede ser menos adecuado que otras tecnologías como SOAP.
OpenAPI (Swagger)
OpenAPI es un estándar ampliamente aceptado para describir servicios web RESTful. Permite a los desarrolladores definir toda la API (endpoints, operaciones, parámetros, respuestas, etc.) en un formato estructurado (generalmente YAML o JSON). Proporciona una interfaz gráfica muy visual donde además se pueden probar los servicios.
OData, la Evolución de REST
Sobre este tipo de servicios web ya tenemos un artículo en el blog. Así que no me voy a repetir.
Comparativa entre SOAP y REST
Son dos tipos de Servicios Web distintos, hay otros pero son los más usados, a pesar de que el REST es relativamente más moderno, no implica que sea mejor o que SOAP sea obsoleto. Cada uno tiene sus ventajas e inconvenientes y sus usos recomendados.
Naturaleza
- SOAP: Es un protocolo estándar más estricto.
- REST: No es un protocolo sino un conjunto de principios arquitectónicos.
Formato de Mensaje
- SOAP: Utiliza XML exclusivamente.
- REST: Puede usar varios formatos como JSON, XML, HTML, texto plano.
Seguridad
- SOAP: Ofrece una mayor seguridad con estándares como WS-Security. Mejor para operaciones que requieren un alto nivel de seguridad.
- REST: La seguridad depende del transporte (como HTTPS). Menos robusto en comparación con SOAP.
Uso de Recursos
- SOAP: Requiere más ancho de banda y recursos debido a su estructura XML más detallada.
- REST: Generalmente más ligero, usando JSON, lo que lo hace más rápido y eficiente en términos de uso de la red.
Operaciones
- SOAP: Ideal para operaciones complejas y con necesidades de transacciones ACID (Atomicidad, Consistencia, Aislamiento, Durabilidad)..
- REST: Adecuado para operaciones más simples y solicitudes de estado. Aunque con OData las posibilidades de «complicar» las operaciones relacionando entidades aumentan su complejidad.
Usos Comunes
- SOAP: Preferido en entornos empresariales. Utilizado para operaciones que requieren un alto nivel de fiabilidad y seguridad, como transacciones financieras.
- REST: Ampliamente utilizado en aplicaciones web y móviles por su simplicidad y facilidad de uso.Ideal para servicios que requieren escalabilidad y rendimiento, como redes sociales, servicios en la nube.
Flexibilidad
- SOAP: Menos flexible en términos de formatos y enfoques.
- REST: Más flexible y fácil de usar. Permite una mayor escalabilidad.
Conclusión
- SOAP es más adecuado para operaciones que necesitan un alto nivel de seguridad y transacciones complejas, comúnmente usado en entornos corporativos y empresariales.
- REST es preferido para aplicaciones que requieren una mayor escalabilidad y rendimiento, siendo más flexible y fácil de implementar, lo que lo hace ideal para aplicaciones web y móviles modernas.
Cada uno tiene sus fortalezas y es importante elegir el enfoque correcto basado en los requisitos específicos del proyecto y del entorno en el que se va a utilizar.