REST frente a SOAP: creación de aplicaciones modernas

Los desarrolladores tienen muchas opciones a la hora de crear aplicaciones modernas. Lenguajes estáticos frente a dinámicos, actores consolidados como Java o relativamente nuevos como Golang, marcos monolíticos todo en uno frente a bibliotecas modularizadas o incluso tener toda la pila funcionando en Javascript son solo la punta del iceberg. A esta lista hay que añadir una importante decisión que los desarrolladores tienen que elegir: REST o SOAP.

REST y SOAP, en pocas palabras, son métodos de comunicación entre aplicaciones. Aunque el objetivo final es el mismo, REST y SOAP no pueden compararse directamente, ya que REST es un conjunto de directrices que los desarrolladores pueden optar por aplicar de forma diferente en un proyecto u otro, mientras que SOAP es un protocolo bien definido y estandarizado para el intercambio de datos. Aun así, se puede hacer una comparación destacando las ventajas e inconvenientes de utilizar uno o el otro. Ambos siguen siendo ampliamente utilizados en el sector y esperamos aclarar por qué y cuándo utilizar uno en lugar del otro.

La Transferencia de Estado Representacional (REST) es un patrón arquitectónico comúnmente utilizado en el desarrollo de aplicaciones web modernas que van desde sitios web, aplicaciones móviles, juegos y más. El desarrollo de una API basada en REST te permite exponer la funcionalidad de tu servicio web a través de HTTP e interactuar con él a través de la web. Utilizando verbos HTTP como GET y POST, el cliente ordena a la API que recupere o cree recursos.

Las API de RESTful han ganado popularidad masiva debido a su interoperabilidad y flexibilidad en la web. Los servicios web construidos con esta arquitectura pueden evolucionar independientemente de las aplicaciones que los consumen. Las API basadas en REST no tienen un protocolo de seguridad bien definido, pero los tokens web JSON (JWT) son el método más habitual para autenticar y autorizar las solicitudes.

A favor

• Sin estado: cada llamada al servicio web tiene toda la información que necesita para procesar la solicitud y no depende del almacenamiento del contexto cliente-servidor.
• Flexible: las API de RESTful pueden aceptar y servir datos en muchos formatos diferentes, como JSON, XML, Atom y otros. JSON es, por mucho, el formato de datos más utilizado en las API basadas en REST.
• Almacenables en caché: las respuestas son almacenables en caché, lo que puede mejorar enormemente el rendimiento del servicio web al eliminar llamadas innecesarias al backend.

En contra

• Estándares: no existe un estándar definido para crear API basadas en REST. Existen muchos recursos y guías excelentes, como los estándares de la API de RESTful de la Casa Blanca y el Tutorial de API de REST, pero existen muchas permutaciones de API basadas en REST.
• HTTP: las aplicaciones RESTful se limitan al protocolo HTTP.

Por su parte, el Protocolo Simple de Acceso a Objetos (SOAP) es un protocolo de intercambio de datos. Su punto fuerte es que cuenta con una serie de reglas y normas que deben respetarse para que las interacciones cliente/servidor sean satisfactorias. Las solicitudes de SOAP se envían a través de sobres que deben contener toda la información necesaria para procesar la solicitud.

Un sobre de solicitud de SOAP suele constar de un encabezado opcional y un atributo de cuerpo obligatorio. El atributo del encabezado se utiliza para información como las credenciales de seguridad y otros metadatos, mientras que el atributo del cuerpo se utiliza para manejar los datos reales y cualquier error que surja. Esto es una simplificación de cómo SOAP maneja el intercambio de datos, por lo que para obtener información más detallada debe consultar la Especificación W3C y si estás impaciente por escribir un servicio web SOAP, intenta con un tutorial fácil de seguir.

A favor

• WSDL: el Lenguaje de Descripción de Servicios Web (WSDL) describe los métodos de servicio web, el acceso y otros parámetros, algo que lo convierte en una ventanilla única para aprender a consumir la API.
• Extensibilidad: las extensiones WS-* como WS-Security, WS-Addressing, WS-Federation y otras pueden mejorar enormemente las capacidades de la aplicación.
• Protocolo neutral: accesible a través de HTTP, SMTP, TCP y otros protocolos de nivel de aplicación.

En contra

• Conjunto de información XML: SOAP utiliza XML para transferir datos de carga útil, cuya serialización puede llevar mucho más tiempo, lo que provoca problemas de rendimiento.
• Sintaxis compleja: SOAP trabaja exclusivamente con XML y la lectura de los sobres de datos puede resultar difícil y llevar mucho tiempo.

Las API de RESTful están por todas partes. Desde las aplicaciones de una sola página hasta el Internet de las Cosas (IoT), los servicios basados en API de REST son la norma. Además de las ventajas técnicas que hemos descrito anteriormente, las API basadas en REST son ideales para muchas empresas porque, en general, son más fáciles de entender y desarrollar. REST es una gran opción para empresas emergentes, aplicaciones móviles y desarrolladores que construyen aplicaciones de página única (SPA) modernas.

Muchas empresas se basan en proporcionar una API de RESTful que resuelva un problema concreto y se integre perfectamente en cualquier aplicación. Auth0 es un gran ejemplo de esto. Otros casos de uso comunes de REST son las empresas que exponen su conjunto de datos y permiten a terceros crear productos a partir de la API expuesta, como la aplicación Falcon creada a partir de la API de RESTful de Twitter.

Los servicios web que utilizan SOAP son habituales en los entornos empresariales. Los grandes entornos empresariales, como los bancarios y de la salud, son los que más se benefician de la utilización de SOAP, ya que les proporciona mayor flexibilidad y control sobre las interacciones cliente/servidor. Expresar métodos complejos es generalmente más fácil con SOAP, así como con transacciones compatibles con ACID.

SOAP es más adecuado para las empresas, pero eso no quiere decir que no pueda o deba utilizarse en proyectos más pequeños. La única advertencia es que la creación de una aplicación de SOAP suele llevar más tiempo, por lo que si solo estás experimentando con una idea, puede que te atasques por la complejidad frente a la entrega real del código. Una prueba de fuego común en el debate de REST frente a SOAP afirma que “si no encuentras una razón específica para construir tu servicio web con SOAP, utiliza REST”.

Las API de REST suelen autenticarse con tokens web Json (JWT). Si es necesario proteger un punto de conexión de API, la estrategia consiste en exigir al cliente que, al realizar una solicitud a la API, incluya un encabezado de autorización que incluya un token que verifique la identidad del solicitante. A continuación, el servidor comprueba que el token sea válido y, si lo es, procesa la solicitud.

Utilizar la autenticación basada en tokens tiene muchas ventajas, que puede conocer aquí. Las API de REST no se limitan a la autenticación basada en tokens: puedes utilizar la autenticación basada en cookies/sesión o incluso crear tu propio mecanismo de autenticación.

Veamos un ejemplo de cómo puedes proteger tu API de RESTful con JWT. Has creado una aplicación móvil que muestra una cita motivadora del día. La cita diaria se recupera mediante una solicitud GET a tu API de RESTful en /api/v1/quote. Los comentarios que has recibido son estupendos y tus usuarios están comprometidos. Quieres darles la posibilidad de enviar sus propias citas a la aplicación.

Se crea un nuevo punto de conexión de RESTful para que cuando se envíe una solicitud POST a /api/v1/quote con los datos requeridos en el cuerpo, la cita enviada se guarde en la base de datos para tu revisión. Pero no quieres que cualquiera te envíe citas. Solo los usuarios registrados deberían poder hacerlo. La implementación de la API es la siguiente:

...

routes.post('/api/v1/quote', function(req, res){
    // getToken es una función de ayuda que busca una clave de Autorización
    // en el encabezado que contiene el valor 'Bearer {token}'
    // luego, elimina la palabra clave Bearer y devuelve solo el  {token}
    var token = getToken(req.headers.authorization);
    var quote = req.body.quote;

    jwt.verify(token, 'secret', function(err, decoded){
        if(err){
            res.json(err) // Detalles del error de devolución
        } else {
            // Save the quote to a database
            res.json({'message':'Quote Successfully Submitted. Thank you!'}); 
        }
    });
});

...

En la implementación anterior, cuando un usuario realiza una solicitud POST al punto de conexión /api/v1/quote, extraemos su JWT y lo almacenamos en una variable llamada token. Si el encabezado de autorización no existe, simplemente detenemos la ejecución, ya que podemos asumir con seguridad que el usuario no está autenticado. Si obtenemos un token, verificamos que sea válido. El token se verifica con el secreto con el que se firmó originalmente. Además, comprobamos si el token ha caducado. El objeto decodificado puede tener datos adicionales, como permisos de usuario, que pueden añadirse cuando se crea el token, pero para nuestra demostración lo hemos hecho simple.

POST a API con JWT válido

POST a API sin JWT

Si todo va bien y no se devuelve ningún error, sabemos que el usuario está autenticado, así que guardamos su cita en la base de datos y le enviamos un bonito mensaje dándole las gracias por utilizar nuestra aplicación. En este ejemplo, hicimos la verificación del token dentro de la implementación del punto de conexión. En una situación real, la verificación del token se realizaría preferiblemente a través de un software intermedio más arriba en la pila de llamadas.

Auth0 puede encargarse fácilmente de generar JWT como parte del flujo de trabajo de autenticación. Una vez que un usuario ha iniciado sesión con éxito, Auth0 devolverá un JWT que almacenarás en el almacenamiento local o en una cookie. A continuación, cada vez que se envíe una solicitud a la API, se añadirá el token en el encabezado bajo una clave de autorización. En el lado del servidor, tendrás que validar este token, que como vimos anteriormente es una tarea sencilla cuando se utiliza uno de los muchos SDK de Auth0.

SOAP es tan flexible como REST a la hora de proteger y autenticar un servicio web. WS-Security es la extensión clave que soporta muchos modelos de autenticación, incluidos credenciales básicas de usuario/contraseña, SAML, OAuth y más.

Una forma habitual de autenticar las API de SOAP es a través del Inicio de sesión único (SSO) de SAML. SAML facilita el intercambio de credenciales de autenticación y autorización entre aplicaciones. Una federación de SAML se compone de tres partes: el usuario, un proveedor de identidades y un proveedor de servicios. El usuario realiza una solicitud desde el proveedor de servicios a un proveedor de identidades y, si la solicitud tiene éxito, el usuario se autentica y puede acceder a la aplicación.

Implementar el SSO de SAML puede ser una tarea desalentadora, difícil y que requiere mucho tiempo. ¡Auth0 puede ayudar! Veamos lo rápido que podemos configurar el SSO de SAML con SSOCircle. Auth0 será el proveedor de servicios, mientras que SSOCircle será el proveedor de identidad, lo que significa que una vez que un usuario intente iniciar sesión, este será llevado a SSOCircle para verificar su identidad.

Con una cuenta de SSOCircle creada, vamos a obtener los metadatos públicos de SSOCircle. Podemos conseguirlos visitando https://idp.ssocircle.com/. Desde aquí, queremos obtener tres atributos, el certificado de firma X509 KeyDescriptor, SingleSignOnService Redirect Location y el SingleLogoutService Redirect Location.

Comenzaremos creando un nuevo archivo .pem para almacenar el certificado al crear un nuevo archivo y copiar el certificado X509. Además, tendremos que añadir los delimitadores Empezar y Finalizar certificado, como se muestra a continuación.

-----EMPEZAR CERTIFICADO-----
MIIDATCCAemgAwIBAgICCpgwDQYJKoZIhvcNAQEFBQAwLjELMAkGA1UEBhMCREUx
EjAQBgNVBAoTCVNTT0NpcmNsZTELMAkGA1UEAxMCQ0EwHhcNMTEwNTE3MTkzNDEx
WhcNMjEwODE3MTkzNDExWjAuMQswCQYDVQQGEwJERTESMBAGA1UEChMJU1NPQ2ly
Y2xlMQswCQYDVQQDEwJDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
ALm1xZq5goTh7NmdzZsZUJed9+7XauwuaNuGyZpIGRo4FsP1YPgs+40mYAoa9rDj
CEekixkfSI6nBUMdHuRIMHogyu/OVxskrL91SLO5m5u9JhgIhO/s9pnmnrnNUILf
RccE4+AEO1xsBQ/x1sY2zDZk+71Pfvifc9vVxedHpNAumbe1nb+CofUtAbF6PkHv
g3pqCoMPmC7m4NAr9h+zq3ekeWf8j5SOicupet9XhsO6zUr0Wga/Zs6J0khhYmFy
zpqoP2rLJ4a/9qduSGslOWsed6kD+zvhLMAUVcw3goli4VhepNzU5iGL9QdVj7m4
YQRMofBRYyL7tBWO6jzLpFcCAwEAAaMpMCcwFAYJYIZIAYb4QgEBAQH/BAQDAgD/
MA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQEFBQADggEBAKmOo8un97VFxNgo
iAzpU5fugKdAFFnKHTvUzDLQ81O455OyT6tcAsXHz6sy2c6GozqDV7xrXSqnues8
p9/w0KzVY9/YuxB90uiSJVh0zMxS+NwyfG1Od5Brloh9eBM4YulUI3V2ustcck17
2G4X4/QSK8uo0bjELUzSNAGj7uypsKKXjX++enfAJzLSsqk3Y8Tmon4R6GYBj4mo
1nL6ujeXqB/kH44XnEmU7ojyIC1kawFRdY4GDFIq3HOBFNzlNbJVL+jKdgTQJTET
rNTDjxXmxwpZ90+lPbEaLQeElwAQi7pMtcqD/f8Dqaifk9ZvpCB7NC+oLM5ej9nK
TawsVqs=
-----FINALIZAR CERTIFICADO-----

Guarda este archivo como SSOCircle.pem. Navega al Panel de control de Auth0 y crea una nueva conexión de Proveedor de identidades de SAMLP al navegar a Connections (conexiones), luego al submenú Enterprise (empresa) y hacer clic en el ícono + en la sección de SAMLP Identity Provider (proveedor de identidades de SAMLP). Hay un montón de opciones que podemos configurar aquí, pero para nuestra demostración, primero vamos a establecer un Nombre de conexión, que puede ser cualquier cosa que elijas. Nos saltaremos los dominios de correo electrónico para esta demostración, pero la sección de dominios de correo electrónico está donde se definen los dominios que funcionarán automáticamente con el inicio de sesión único.

Las URL de inicio y fin de sesión las hemos recibido de los metadatos públicos de SSOCircle, así que las insertaremos aquí. La última parte de la configuración es cargar el certificado .pem que creamos anteriormente. Una vez configurados estos parámetros, podemos ignorar el resto y hacer clic en “guardar”.

Después de guardar la configuración, se te pedirá que continúes y tendrás que obtener los metadatos de tu conexión. Debería verse así:

<EntityDescriptor entityID='urn:auth0:{ACCOUNT_NAME}:{CONNECTION_NAME}' xmlns='urn:oasis:names:tc:SAML:2.0:metadata'>
  <SPSSODescriptor WantAssertionsSigned='true' protocolSupportEnumeration='urn:oasis:names:tc:SAML:2.0:protocol'>

    <SingleLogoutService Binding='urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect' Location='https://{ACCOUNT_NAME}.auth0.com/samlp/logout'/>
    <SingleLogoutService Binding='urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST' Location='https://{ACCOUNT_NAME}.auth0.com/samlp/logout'/>
    <NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</NameIDFormat>
    <NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</NameIDFormat>
    <NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</NameIDFormat>
    <AssertionConsumerService Binding='urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST' Location='https://{ACCOUNT_NAME}.auth0.com/login/callback?connection={CONNECTION_NAME}' index='0' isDefault='true'/>
  </SPSSODescriptor>
</EntityDescriptor>

Estos son tus metadatos de conexión y los utilizarás para registrar un nuevo Proveedor de servicios en SSOCircles. Ve a SSOCircle y navega hasta la sección “Gestionar metadatos”. Una vez allí, haz clic en “Añadir nuevo proveedor de servicios”. Deberás introducir el nombre de dominio completo (FQDN), que en nuestro caso será auth0.com, seleccionar “Dirección de correo electrónico” en los atributos enviados en la sección de aserción y finalmente pegar los metadatos XML en el área de texto proporcionada. Haz clic en “Enviar” y el proveedor de servicios de Auth0 quedará registrado.

Para comprobar que la conexión fue exitosa, haz clic en el botón de gestión situado bajo la sección “Proveedor de identidades de SAMLP” y, a continuación, en “Intentar” (que es el icono de reproducción). Si todo ha ido bien, deberías ver una pantalla como la siguiente. ¡Ya está! Has integrado el Inicio de sesión único de SAML con Auth0 actuando como el Proveedor de servicios y SSOCircle actuando como el Proveedor de identidades. Para obtener una guía más detallada sobre la implementación de una federación de SAML, consulta los documentos.

Ya sea que estés construyendo una aplicación móvil que consume servicios de RESTful o una aplicación de SOAP empresarial, Auth0 te asiste cuando se trata de autenticación.

La autenticación de JWT es el pan de cada día de Auth0. Con una amplia biblioteca de autenticación, así como SDK para muchos lenguajes de programación y marcos de trabajo, puedes tener la autenticación en funcionamiento en cuestión de minutos. El soporte para más de 30 conexiones sociales, incluidos Facebook, Twitter y Google, así como la capacidad de utilizar una base de datos de usuarios existente, hace que el cambio a Auth0 sea pan comido.

Auth0 puede actuar como proveedor de servicios y como proveedor de identidades en una federación basada en SAML. Aplicaciones como Salesforce o Box pueden utilizar Auth0 como Proveedor de identidades para permitir a los usuarios iniciar sesión en dichos servicios a través de Auth0. En el caso de que Auth0 actúe como Proveedor de servicios, Auth0 enviará una solicitud de autorización a un Proveedor de identidades como SSOCircle, OneLogin o cualquier otro Proveedor de identidades compatible con SAML.