Remote Procedure Calls (RPC, Llamadas a Procedimientos Remotos): Los Servicios Web basados en RPC presentan una interfaz de llamada a procedimientos y funciones distribuidas, lo cual es familiar a muchos desarrolladores. Típicamente, la unidad básica de este tipo de servicios es la operación WSDL (WSDL es un descriptor del Servicio Web, es decir, el homólogo del IDL para COM). Las primeras herramientas para Servicios Web estaban centradas en esta visión. Algunos lo llaman la primera generación de Servicios Web. Esta es la razón por la que este estilo está muy extendido. Sin embargo, ha sido criticado por no ser débilmente acoplado, ya que suele ser implementado por medio del mapeo de servicios directamente a funciones específicas del lenguaje o llamadas a métodos. Muchos especialistas creen que este estilo debe desaparecer.
Arquitectura Orientada a Servicios (Service-oriented Architecture, SOA)
Hay que tener cuidado cuando se manejan los términos y no confundirlos. SOA no es lo mismo que Web Services (servicios web), ya que este último término engloba varias tecnologías, incluyendo XML, SOAP, WSDL, UDDI…los cuales permiten construir soluciones de programación para mensajes específicos y para problemas de integración de aplicaciones.
Sin embargo, los Servicios Web pueden también ser implementados siguiendo los conceptos de la arquitectura SOA de aplicación, en la cual todas las funciones están definidas como servicios independientes con interfaces invocables que pueden ser llamados en secuencias bien definidas para formar los procesos de negocio. SOA es una filosofía de diseño independiente de cualquier proveedor, producto, tecnología o industria.
Este paradigma surge de la influencia de diferentes modelos como pueden ser: la orientación a objetos, BPM, orientación a aspectos y web services.
SOAP (Simple Object Access Protocol). Es un protocolo para el manejo de Servicios Web el cual está basado XML y su objetivo es la comunicación entre servicios los cuales tengan expuesto con contratos (WSDL: Web Services Description Language). Actualmente, si hablamos de este protocolo me sabe que pueden exponer dos tipos: SOAP 1.1 o SOAP 1.2, así mismo manejar una comunicación varios tipos que son: Síncrono, Asíncrono y Oneway (XML en realidad).
Los Servicios Web basados en SOAP son soportados por la mayor parte de desarrolladores de software y analistas. Al contrario que los Servicios Web basados en RPC, este estilo es débilmente acoplado, lo cual es preferible ya que se centra en el “contrato” proporcionado por el documento WSDL, más que en los detalles de implementación subyacentes.
En la imagen se muestra cómo evolucionó una arquitectura SOAP, la cual anteriormente cuando no se conocía el concepto del bus de servicios (ESB), toda la comunicación era en modo: Punto a Punto (no estaba controlada), ya posteriormente con la entrada del ESB, todo cambio y ese era el encargado de la comunicación, seguridad, redireccionamiento, exposición, etc.
SOA y SOAP suelen ser términos que, a menudo, suelen generar bastante confusión (quizá por la semejanza de sus siglas). Parece que muchas veces no tenemos del todo claro dónde empieza y acaba cada cosa aunque, en el fondo, sabemos que existe relación entre ambos términos. Incluso es común encontrar por ahí algunos artículos donde se refieren a SOA cuando realmente quieren decir SOAP.
WSDL y UDDI
WSDL – Web Services Description Language. Es un protocolo basado en XML que describe los accesos al Web Service. Podríamos decir que es el manual de operación del web service, porque nos indica cuales son las interfaces que provee el Servicio web y los tipos de datos necesarios para la utilización del mismo.
UDDI – Universal Discovery Description and Integration. Es un modelo de directorios para Web Services. Es una especificación para mantener directorios estandarizados de información acerca de los Web Services, sus capacidades, ubicación, y requerimientos en un formato reconocido universalmente.
UDDI utiliza WSDL para describir las interfaces de los Web Services.
Es un lugar en el cual podemos buscar cuales son los Servicios web disponibles, una especie de directorio en el cual podemos encontrar los Web Services publicados y publicar los Web Services que desarrollemos.
REST (Representation State Transfer). Se trata de un diseño de arquitectura particular y cuando se utiliza el término RESTful, se hace referencia a una aplicación que usa dicha arquitectura.
Los Servicios Web basados en REST intentan emular al protocolo HTTP o protocolos similares mediante la restricción de establecer la interfaz a un conjunto conocido de operaciones estándar (ejemplo CRUD). Por tanto, este estilo se centra más en interactuar con recursos con estado, que con mensajes y operaciones. Así mismo, dicho protocolo puede manejar una comunicación basada en XML & JSON (Formatos distintos), exponer URIs y de manejar si se requiere un contrato similar al del protocolo SOAP (WSDL)
Otro término importante es el de API (Application Programming Interface), que se trata de una aplicación de software con la que podemos interactuar pero vía programación, en lugar de vía interfaz gráfica, con su código fuente, haciendo uso de funciones y rutinas de dicha aplicación.
RESTful consiste en el manejo de servicios web pero aplicando en su comunicación el protocolo REST, pero correctamente esto quiere decir que para que se le reconozca que se está aplicando RESTful se daría únicamente si llegara a cumplir en su manejo con las operaciones estándar CRUD: GET, POST, PUT, DELETE, etc.
Es una forma común de exponer partes de su aplicación a terceros (aplicaciones externas y sitios web). Puede estar orientado a los datos, en un sentido que su servicio web (la API RESTful), simplemente haga disponible la información que almacena en sus bases de datos utilizando un formato común, como XML o JSON.
Los métodos HTTP más importantes son PUT, GET, POST y DELETE. Ellos suelen ser comparados con las operaciones asociadas a la tecnología de base de datos, operaciones CRUD: CREATE, READ, UPDATE, DELETE. Otras analogías pueden también ser hechas como con el concepto de copiar-y-pegar (Copy&Paste). Todas las analogías se representan en la siguiente tabla:
| Acción | HTTP | SQL | Copy&Paste | Unix Shell |
| Create | PUT | Insert | Pegar | > |
| Read | GET | Select | Copiar | < |
| Update | POST | Update | Pegar después | >> |
| Delete | DELETE | Delete | Cortar | Del/rm |
De esta manera, una aplicación externa puede interactuar con su aplicación y sus datos, sin tener que conectarse directamente a su base de datos. De esta manera, no importa si su base de datos es MySQL o PostgreSQL, o si su aplicación fue escrita en Java o Python. Pero las API RESTful también pueden usarse para modificar datos.
GraphQL. Impulsado por Facebook (creado en 2012 y publicado en 2015) es un lenguaje de manipulación y consulta de datos de código abierto para las API.
Aunque REST es un claro caso de éxito, ha sido considerado que su concepción CRUD basada en resources, verbos y códigos de respuesta HTTP puede representar desventajas. La necesidad de avanzar más rápido en productos cada vez más complejos, más allá de un simple CRUD, ha empujado un cambio en la forma en que interactuamos con las APIs. Tanto, que algunos dicen que es un sustituto de REST.
Con GraphQL, es el cliente el que le dice al servidor cómo quiere que le devuelvan los datos. Precisamente de aquí viene lo del “QL”, es decir, Query Language. Busca acercarnos a un SQL para los servicios web.
