Investigación sobre el desarrollo de Api de comunicación con un servidor.

Para llevar a cabo una web o aplicación móvil, es necesario desarrollar un sistema de comunicación con el servidor con el que la aplicación se comunicará para recibir y enviar datos. La forma más habitual de comunicarse con el servidor es a través de una comunicación HTTP o HTTPS utilizando uno de los dos servicios más extendidos: SOAP y REST.

En este apartado haré una breve descripción de estas técnicas y explicaré mi recomendación. Por último os invito que visiteis el video https://www.youtube.com/watch?v=QKFBKafxeco dónde realizo un análisis del artículo.

1.SOAP

Los servicios SOAP o conocidos simplemente como Web Services, son servicios que basan su comunicación bajo el protocolo SOAP (Simple Object Access Protocol) el cual este definido por Wikipedia como "protocolo estándar que define cómo dos objetos en diferentes procesos pueden comunicarse por medio de intercambio de datos XML". Por lo tanto, queda claro que la comunicación se realiza mediante XML. Los servicios SOAP funcionan por lo general por el protocolo HTTP, aunque pueden utilizar otros protocolos como el Ftp.

Normalmente, estos servicios los utilizaremos para la comunicación de Server to Server o Partner to Partner pues es un protocolo mucho más robusto que permite agregar metadatos mediante los atributos del propio sistema XML (cosa que JSON no tiene) y definir espacios de nombre con el objetivo de evitar la ambigüedad. Por lo mismo, SOAP es un formato más pesado, tanto en tamaño como en procesamiento, pues los XML tiene que ser parseado a un árbol DOM, resolver espacios de nombre (namespaces) antes de poder empezar a procesar el documento. Los XML además tienen métodos de validación muy potentes y ampliamente utilizados, a diferencia de JSON, el cual, sí tiene forma de validar, pero no son tan potentes y su utilización es menor.

2. REST

REST es una tecnología flexible que transporta datos a través de los diversos medios que le proporciona el protocolo HTTP, como son:

GET: Se utiliza para consultar, leer y en definitiva acceder a un recurso
POST: Envía datos para crear un recurso. Como en cualquier petición POST, los datos deben ir incluidos en el cuerpo de la petición.
PUT: Utilizado para editar un recurso. Al igual que el POST, los datos deben ir en el cuerpo de la petición.
DELETE: Es la opción para eliminar un recurso
PATCH: Se utiliza para modificar parcialmente un recurso, aunque se utiliza en muy pocas ocasiones. Normalmente se utiliza simplemente PUT

Y además, incorpora los códigos de respuesta nativos como:

200 OKSolicitud aceptada; la respuesta contiene el resultado.
201 CREATED Las operaciones PUT o POST devuelve este código de respuesta e indica que se ha creado un recurso de forma satisfactoria.
204 NO CONTENT Indica que se ha aceptado la solicitud, pero no había datos para devolver.
400 BAD REQUEST La solicitud no fue válida.
401 UNAUTHORIZED El servidor de aplicaciones devuelve este código de respuesta cuando está habilitada la seguridad y faltaba la información de autorización en la solicitud.
403 FORBIDDEN Indica que el cliente ha intentado acceder a un recurso al que no tiene acceso.
404 NOT FOUND Indica que el recurso de destino no existe.
406 NOT ACCEPTABLE El recurso de destino no admite el formato de datos solicitado en la cabecera de Accept o el parámetro accept.
409 CONFLICT Indica que se ha detectado un cambio conflictivo durante un intento de modificación de un recurso.
415 UNSUPPORTED MEDIA TYPE El recurso de destino no admite el formato de datos del cuerpo de la solicitud especificada en la cabecera de Content-Type.
500 INTERNAL SERVER ERROR Se ha producido un error interno en el servidor.

El cliente inicia siempre una solicitud con la finalidad de solicitar al servidor un determinado recurso utilizando su propio lenguaje. Tanto el cliente como el servidor se comunican en un formato de intercambio de información tan flexible que permite transmitir prácticamente cualquier tipo de datos, ya que el tipo de datos está definido por el Header Content-Type, lo que nos permite mandar, XML, JSON, Binarios (imágenes, documentos), textos, etc. que contrasta con SOAP que solo permite la transmisión de datos en formato XML. A pesar de la gran variedad de tipos de datos que podemos mandar con REST, la gran mayoría transmite en JSON por un motivo muy importante, JSON es interpretado de forma natural por JavaScript, lo que ha hecho que frameworks como Angular y React se aprovechen al máximo, pues pueden enviar peticiones directas al servidor por medio de AJAX y obtener los datos de una forma nativa.

Lo importante es que el cliente no recibe HTML para renderizar, sino simplemente los datos que se han generado como respuesta. Es decir, el servidor no escribe HTML, sino únicamente genera los datos para enviarlos al cliente.

Otro punto importante es la independencia con la tecnología escogida de programación o base de datos escogida. Podrás tener un servidor que trabaja con PHP, Java, Python, NodeJS o lo que prefieras, o te imponga el proyecto. Tanto el lenguaje como la base de datos son importantes, porque nos sirven para procesar la solicitud y generar la respuesta, pero no importa cómo lo hagas en el servidor. Simplemente que la respuesta la entregues en ese lenguaje de intercambio de información que estés usando, generalmente JSON.

3. Conclusión

Gracias al estudio previo que hemos realizados, hemos podido analizar y diferenciar los dos servicios con el objetivo de escoger la mejor opción.

Por un lado tenemos en el servicio SOAP, un sistema de comunicación mediante archivos XML basado en la robustez y experiencia. Normalmente se suele utilizar a través protocolo HTTP, sin embargo, SOAP no está limitado a este protocolo, si no que puede ser enviado por FTP, POP3, TCP, Colas de mensajería (JMS, MQ, etc).

Ahora bien, entre sus principales problemas nos encontramos:

Su complejidad.
No funciona muy bien con dispositivos móviles y aplicaciones RIA basadas en javascript. (Una rich Internet application (RIA), aplicación de Internet enriquecida o aplicación rica de internet (ARI), es una aplicación web que tiene la mayoría de las características de las aplicaciones de escritorio tradicionales. Estas aplicaciones utilizan un navegador web estandarizado para ejecutarse y por medio de complementos o mediante una máquina virtual se agregan las características adicionales.)
Es ineficiente desde el punto de vista del ancho de banda.El propio uso de este servicio implica un consumo mayor del ancho de banda justamente por la estructura que requieren estos paquetes (Cabecera, tipos, etc).
No aprovecha la infraestructura web, como caches, negociación de formatos, negociación de idioma, seguridad, sistema de concurrencia optimista, etc.
Problemas con el firewall. SOAP usa el protocolo HTTP como un mero medio de transporte. No aprovecha sus características, y subvierte la semántica de este último. Esto hace que las llamadas SOAP sean “opacas” desde el punto de vista de la infraestructura web, como caches o firewalls.

Por lo tanto, no sería la mejor opción para nuestro proyecto ya que nuestra aplicación web necesitaría una solución más sencilla, optimizada y adaptable.

Desde punto de vista del backend, necesitamos proporcionar al frontend una manera sencilla de obtener los datos que requieren las interfaces de usuario, como serían una app móvil Android, iOS o una interfaz web hecha en React . Por lo tanto, la mejor solución para el proyecto sería implementar una API REST consistente, donde podríamos alimentar las distintas interfaces, y además, proporcionar nuestra fuente de servicios para el consumo por parte de terceros.

Buscando una definición sencilla, REST es cualquier interfaz entre sistemas que use HTTP para obtener datos o generar operaciones sobre esos datos en todos los formatos posibles, como XML y JSON. Y sería la alternativa perfecta al SOAP, que disponen de una gran capacidad pero también mucha complejidad.