Header Ads Widget

Ticker

6/recent/ticker-posts

Uso de hipermedia para diseñar interfaces de usuario basadas en eventos

 


Algunas de las tecnologías más poderosas ahora se basan completamente en una estructura API . Las API web son excelentes porque pueden entregar datos y funcionalidad a través de HTTP u otros protocolos, lo que significa plataformas de cliente independientes, una capacidad de evolución más fácil y diseños más eficientes. Teniendo en cuenta el diseño de API , aunque los titulares como GraphQL o gRPC están llamando la atención, REST , como lo define Roy Fielding, sigue siendo un estilo campeón.

En nuestro esfuerzo por encontrar las mejores prácticas de API REST impresionantes , hemos cubierto lo que significa diseñar una verdadera máquina REST (y aclaramos esos puntos ). Las API también merecen una gestión de cambios de calidad para que sea eficaz y evolutiva.

Hemos visto que, aunque REST ful API de transferencia de datos y función bien a través de una variedad de dispositivos cliente,  verdaderamente API REST que adoptan hipermedia pueden encender interconectadas, orientadas a eventos flujos. Hypermedia puede habilitar aplicaciones robustas y evolutivas que reducen el peso del cliente. Pero, ¿cómo funciona la hipermedia en la práctica? Lo más importante, ¿cómo funcionaría realmente una aplicación web nativa de hipermedia ?

Una vez más, acudimos al autor y orador veterano de las API nórdicas, Asbjørn Ulsberg, para obtener una respuesta. Asbjørn sugiere que los desarrolladores de API consideren una combinación de interfaces de usuario de composición con vistas alojadas e hipermedia para crear aplicaciones web reactivas basadas en eventos.

Este artículo describe una excelente charla dada por Asbjørn Ulsberg en la Cumbre de Plataformas de las APIs nórdicas 2018:

Hipermedia, vistas alojadas y UI de composición

Primero, definamos estos tres términos, ya que se volverán importantes a medida que describamos la composición de una interfaz de usuario nativa de hipermedia.

1. Hipermedia

El hipermedia es la restricción REST final, y los fanáticos dirían que la más importante. Como hemos comentado anteriormente , los hipermedios ponen un mayor énfasis operativo en los recursos con posibilidades, ubicados en  URI . Las API de hipermedia son condicionales ; reactivo a cuándo y quién está dando la solicitud. Por lo tanto, puede pensar en hipermedia como un menú y una receta, una forma de describir qué opciones tiene y cómo realizarlas.

Mientras conduces por una ciudad, no sigues un viejo mapa de carreteras estático: confías en los semáforos, las señales de tráfico, los desvíos de la construcción y otros obstáculos en tu camino directo. Del mismo modo, hipermedia funciona en tiempo de ejecución y está condicionado a la naturaleza de la solicitud.

"Esta condicionalidad en tiempo de ejecución de los hipermedia es una de sus grandes fortalezas"

2. Vistas alojadas

Las vistas alojadas son esencialmente componentes web conectados a una API del lado del servidor, a menudo un microservicio . Específicamente, las vistas alojadas se implementan usando <iframe>JavaScript y mediante una API del lado del servidor. Las vistas alojadas se implementan comúnmente con este método, sin embargo, los componentes web son un estándar en crecimiento que podría reemplazar este método una vez que madure.

3. IU de composición

Composición : El acto de combinar partes o elementos para formar un todo.

Las IU de composición pueden ser páginas completas, iframes, ventanas emergentes u otros objetos de ventana. Asbjørn reconoce que estos componentes funcionan de forma independiente y se basan en un protocolo de comunicación estándar . En JavaScript, esto se hace usando window.postMessage(), junto con devoluciones de llamada a las que cada componente puede suscribirse.

Ejemplo de implementación de hipermedia: tienda en línea

Entonces, ¿cómo se articulan estos tres aspectos en la práctica? Asbjørn sugiere que consideremos cómo funciona una tienda en línea . Las tiendas en línea no quieren manejar el procesamiento de pagos por sí mismas; es una gran carga técnica y estos datos confidenciales también son difíciles de navegar a raíz del GDPR .

Para que un usuario revise un carrito de compras en línea, por ejemplo, se requieren datos de usuario y de pago . Afortunadamente, estos datos se pueden recopilar e insertar utilizando vistas alojadas , que subcontratan la carga a otros.

Para albergar una vista que pueda recopilar datos del usuario, Asbjørn describe cómo puede verse una solicitud de API. Primero, hacemos una POSTllamada para crear un recurso de inicio de sesión:

POST /logins HTTP/1.1
Authorization: Bearer f489l3…
Host: api.example.com

La respuesta enumera algunas operaciones que pueden proporcionar pistas alternativas para iniciar sesión:

HTTP/1.1 201 Created
Content-Type: application/json Location: https://api.example.com/logins/38237dfyw78 { "id": "https://api.example.com/logins/38237dfyw78", "operations": [{ "rel": "login", "method": "GET", "href": "https://api.example.com/logins/38237dfyw78.js", "contentType": "application/javascript" }] }

Notará que la loginoperación anterior también incluyó una hrefpropiedad que apunta a un URI . El siguiente paso es tomar ese URI e incrustarlo en la página web.

Aquí hay un fragmento de cómo insertar el URI dentro de una etiqueta de secuencia de comandos, con el atributo de datos apuntando a divdonde queremos que se aloje la vista.


Esto dará como resultado la creación de una vista de inicio de sesión en un sitio de comercio electrónico. La belleza de esto es que se desarrolló hipermedia, como en Hypermedia como motor de estado de aplicación (HATEOAS) .

Ahora, cuando iniciamos sesión, esto ocurre dentro de la vista alojada:

POST /logins/38237dfyw78/identifications HTTP/1.1
Authorization: Bearer f489l3…
Host: api.example.com
Content-Type: application/json

{
	"identify": {
		"email": "text@example.com",
		"phone": "5555555555"
	}
}

Por tanto, la vista alojada recopila los datos del formulario HTML y los envía como una solicitud de API a su API de backend. Si se identifica al usuario, recibiremos una 302 Foundrespuesta. La composición de la respuesta de identificación puede variar, especialmente dependiendo de si está utilizando una suite de administración de identidades con OAuth y OpenID Connect.

Independientemente, la 302 Foundrespuesta ahora se traduce en una devolución de llamada de evento de JavaScript denominada  identificada por el consumidor . La tienda almacenará el URI con el consumidor identificado para su uso posterior. Una 302 Foundrespuesta de identificación probablemente también detallará una propiedad de operaciones , que contiene un parámetro que sugiere una operación posterior a realizar. Por ejemplo, dicha operación puede incluirse dentro de una respuesta de identificación:

...
"operations": [{
	"rel": "next acquire-shipping-address",
	"method": "POST",
	"href": https://api.example.com/consumers/38237dfyw78/addresses
	"expects": {
		"address": "string",
		"city": "string",
}
...

Arriba, vemos que la siguiente operación es recopilar una dirección de envío, incluyendo qué datos aceptar y de qué tipo; en este caso, ambos son cadenas. Puede haber múltiples operaciones potenciales futuras para realizar, por lo que el uso de relaciones de enlace con nextnos permite distinguirlas y ayuda a informar a la vista alojada qué operaciones realizar a continuación.

A su vez, un formulario HTML se vería así:


Este formulario puede luego representar una vista dentro del contenedor. Asbjørn señala que todo lo que necesitamos realizar en esta solicitud estaba disponible en la respuesta anterior, lo que significa que la interfaz es completamente sin estado .

“La interfaz no tiene lógica sobre cómo construir la URI; el URI es un identificador completamente opaco y nada más "

Asbjørn ve algunos beneficios en no obligar a los clientes a crear URI. Le quita la carga al cliente. Significa que la API no tiene que exponer identificadores internos al mundo externo; solo usa URI opacos como identificadores; desacoplar el cliente del servidor.

Para finalizar la implementación de compras, continuaríamos tomando URI dentro operationsde las respuestas de la API y los agregaríamos a los documentos HTML para luego afectar la interfaz del usuario final. Ahora, cuando alguien completa el formulario, se realiza una solicitud de dirección de envío contra la API de backend en función de la operación que se encuentra en la respuesta de identificación inicial. Luego, recibiríamos una respuesta de la solicitud de dirección de envío, que podría convertirse en un evento de envío de dirección. Se puede utilizar un proceso similar para iniciar pagos y mostrar páginas de pagos recibidos utilizando vistas alojadas.

Para llevar

Una vez que los eventos en el front-end se comunican mediante un protocolo de mensajes, dichos componentes se desacoplan entre sí, haciéndolos reutilizables  y permitiéndoles cambiar de forma independiente. En general, es una gran idea detallar posibles acciones adicionales como enlaces hipermedia dentro de las respuestas de la API. Como señala Asbjørn, esto permitirá el control de acceso basado en roles (RBAC) y otras variaciones de estado.

Al usar hipermedia que se encuentra en las respuestas de dichas API de backend, las IU de composición se vuelven reactivas y controladas por eventos. Al hacerlo, la lógica empresarial y la complejidad se eliminan de las interfaces del cliente y se colocan en la API. Dado que este método pone más énfasis en los URI, Asbjørn nos recuerda que no expongamos identificadores internos al cliente: la construcción del URI del lado del cliente provoca el acoplamiento.

Creación de una arquitectura hipermedia impulsada por eventos

En este artículo, hemos visto cómo se puede utilizar hipermedia en la práctica para crear interfaces de usuario de composición interconectadas. Al basar las acciones posteriores en operaciones anidadas dentro de las respuestas de la API, el hipermedia permite a los desarrolladores crear experiencias inteligentes sin estado, todas basadas en la URI ubicua .

Los procesos de autodocumentación son comunes en el mundo físico y también pueden comportarse bien en el ámbito digital. Como describe Asbjørn, la hipermedia es similar a:

"... un proceso de auto-documentación que le brinda pistas sobre lo que puede realizar en cada etapa"

Para algunos, la adopción de HATEAOS puede ser una molestia y puede no ser relevante para todos los escenarios. Sin embargo, PayEx está construyendo su Checkout utilizando esta arquitectura exacta, por lo que parece funcionar en la práctica. Los formatos hipermedia como Siren , Hydra y JSON Hyper-Schema también pueden ayudar a facilitar la adopción.

Recursos

Publicar un comentario

0 Comentarios