Investigación sobre el desarrollo de API de comunicación con un servidor

1. SOAP

Los servicios SOAP, conocidos también como Web Services, basan su comunicación en el protocolo SOAP. Se trata de un protocolo estándar que define cómo dos objetos en diferentes procesos pueden comunicarse mediante intercambio de datos XML.

Por tanto, la comunicación se realiza mediante XML. Estos servicios suelen funcionar sobre HTTP, aunque también pueden utilizar otros protocolos como FTP.

Normalmente, SOAP se utiliza en escenarios server-to-server o partner-to-partner, ya que es un protocolo más robusto y permite incorporar metadatos mediante atributos del propio XML, así como definir espacios de nombres.

Precisamente por ello, SOAP es un formato más pesado, tanto en tamaño como en procesamiento. Los documentos XML deben parsearse, resolverse sus espacios de nombres y validarse antes de comenzar su tratamiento.

Además, XML dispone de mecanismos de validación muy potentes. JSON también puede validarse, pero tradicionalmente su ecosistema de validación ha sido más ligero y menos rígido.

2. REST

REST es una tecnología flexible que transporta datos utilizando los distintos métodos que proporciona el protocolo HTTP, como por ejemplo:

• GET: consultar o leer un recurso.
• POST: enviar datos para crear un recurso.
• PUT: editar un recurso existente.
• DELETE: eliminar un recurso.
• PATCH: modificar parcialmente un recurso.

Además, REST aprovecha los códigos de respuesta estándar del propio protocolo HTTP, como:

• 200 OK: solicitud aceptada y respuesta correcta.
• 201 CREATED: recurso creado satisfactoriamente.
• 204 NO CONTENT: solicitud aceptada, sin datos para devolver.
• 400 BAD REQUEST: solicitud inválida.
• 401 UNAUTHORIZED: falta autorización.
• 403 FORBIDDEN: acceso prohibido al recurso.
• 404 NOT FOUND: el recurso no existe.
• 406 NOT ACCEPTABLE: formato solicitado no soportado.
• 409 CONFLICT: conflicto en la operación solicitada.
• 415 UNSUPPORTED MEDIA TYPE: tipo de contenido no soportado.
• 500 INTERNAL SERVER ERROR: error interno del servidor.

En REST, el cliente inicia la solicitud con el objetivo de obtener o modificar un recurso. Cliente y servidor intercambian información utilizando un formato flexible definido por la cabecera Content-Type.

A diferencia de SOAP, que se centra exclusivamente en XML, REST se utiliza de forma muy habitual con JSON, especialmente porque JavaScript lo interpreta de forma nativa. Esto ha permitido que frameworks como Angular o React aprovechen esta ventaja para consumir APIs de forma directa y eficiente.

Lo importante es que el cliente no recibe HTML para renderizar, sino únicamente los datos generados como respuesta. Es decir, el servidor no construye la interfaz, sino que entrega los datos para que el frontend los procese.

Otro punto importante es su independencia respecto a la tecnología de backend o de base de datos utilizada. El servidor puede estar desarrollado en PHP, Java, Python o Node.js; lo importante es que exponga la información utilizando un formato de intercambio adecuado, generalmente JSON.

3. Conclusión

Gracias al análisis previo, hemos podido diferenciar ambas soluciones con el objetivo de escoger la mejor opción para una aplicación web moderna.

SOAP ofrece una solución robusta, madura y muy estructurada, basada en XML y con gran capacidad de validación. Sin embargo, también presenta varios inconvenientes:

• Mayor complejidad de implementación y procesamiento.
• Peor adaptación a dispositivos móviles y aplicaciones web ricas.
• Mayor consumo de ancho de banda.
• Menor aprovechamiento de la infraestructura nativa de la web.
• Más fricción con elementos intermedios como cachés o firewalls.

Por ello, SOAP no sería la opción más adecuada para este proyecto, ya que nuestra aplicación web necesita una solución más ligera, optimizada y adaptable.

Desde el punto de vista del backend, necesitamos proporcionar al frontend una manera sencilla de obtener los datos que requieren distintas interfaces de usuario, como una aplicación Android, iOS o una interfaz web desarrollada en Angular o React.

En este contexto, la mejor solución es implementar una API REST consistente, capaz de alimentar diferentes interfaces y, además, servir como fuente de servicios para terceros.

En resumen, REST puede entenderse como una interfaz entre sistemas que utiliza HTTP para obtener datos o realizar operaciones sobre ellos en formatos como XML o JSON. Frente a SOAP, representa una alternativa más simple, flexible y adecuada para la mayoría de aplicaciones web actuales.

Checklist para diseñar una API

Una API útil debe exponer recursos claros, códigos de estado previsibles, reglas explícitas de autenticación y versionado antes de que el frontend empiece a depender de ella. REST no es solo una forma de enviar JSON: también es un contrato entre equipos y aplicaciones.

En proyectos Angular, este contrato es especialmente importante porque HttpClient, guards, interceptores y carga de datos compatible con SSR dependen de endpoints estables.