Header Ads Widget

Ticker

6/recent/ticker-posts

Revisión de ALPS


La semántica de perfil a nivel de aplicación (ALPS) es un nuevo formato para describir los servicios web. Si bien tiene un alcance más limitado para definir el "qué" de una API, promete algunas ganancias interesantes en la reorientación del esfuerzo en el espacio de diseño de API. Hoy, veremos ALPS y describiremos sus características principales. También veremos la nueva utilidad unificada ALPS de código abierto , una nueva oferta de sus creadores que promete generar especificaciones a partir de la definición.

¿Qué es ALPS? La API Tabula Rosa

ALPS es un formato para describir servicios web. Más específicamente, ALPS es un formato para diseñar un servicio mediante el mapeo de las operaciones y los elementos de datos de cada servicio. Básicamente, ALPS proporciona una forma unificada de documentar el servicio en un formato agnóstico que es comprensible independientemente de las herramientas, la perspectiva (del lado del cliente o del lado del servidor), protocolos o arquitecturas.

Para dar un breve desvío, analicemos el concepto de contexto acotado . En el diseño impulsado por dominios, el contexto acotado es el foco de definición y comprensión dentro de una estructura determinada. En el espacio de la API, las funciones utilizadas para llevar a cabo una acción específica son las mismas independientemente de quién las esté usando, siempre que estén dentro del área del contexto delimitado; esto asegura que el contexto se mantenga y se comprenda en una variedad de implementaciones . Según Mike Amundsen, el creador de ALPS, se puede pensar en ALPS de la misma manera :

“ALPS no impone ningún requisito sobre las URL, lo que no significa que los implementadores de servicios no utilicen las URL cuando crean un servicio basado en un perfil de ALPS.

"¿Cómo se implementa en un marco MVC para manejar las asignaciones de las API?" puede hacer esto de la forma que desee. ALPS no restringe el uso de URL por parte de las implementaciones. Tus URL son tuyas.

ALPS está diseñado para compartir un entendimiento común en múltiples implementaciones. por ejemplo, un perfil "todo" de ALPS contendría todos los elementos de datos (título, id, completado) y acciones (nuevo, editar, markComplete, eliminar, listAll, listActive, listCompleted, clearCompleted) para el servicio. Básicamente, ALPS puede ser una versión legible por máquina [0] de la especificación de funcionalidad TodoMVC legible por humanos [1].

También puede pensar en ALPS como una versión legible por máquina del "BoundedContext" de Eric Evan: las cosas que un servicio comparte con el "mundo exterior".

Para citar más a Amundsen, "ALPS le dice el QUÉ del servicio, no el CÓMO". Esto es de vital importancia, ya que la complejidad de un sistema a menudo puede nublar su propósito: podemos quedarnos absortos en la mecánica real de cómo una API hace algo sin realmente irnos entendiendo lo que hace. De esta manera, se puede pensar en ALPS como la “Tabula Rosa” de las API, una metodología unificadora mediante la cual una API podría traducirse y entenderse en múltiples formatos, instancias e implementaciones.

Cómo funciona ALPS

Para empezar, ALPS define los límites del dominio del problema (como se define en la documentación, los "posibles elementos de datos y posibles transiciones de estado"). Para las API, los ALP definen posibles identificadores para valores de datos mediante el uso de perfiles. De esta manera, si un servicio admite un perfil (por ejemplo, "glogging"), todos los valores de datos (como "givenName) y las transiciones (como" publicar ") deben entenderse comúnmente. Estos perfiles se pueden anunciar a través de respuestas HTML utilizando varios métodos:

  • Encabezado de enlace : el Linkencabezado, en combinación con los valores hrefrel, puede dirigir a los usuarios al perfil (ejemplo:) .Link: http://alps.io/profiles/microblogging; rel="profile"
  • Atributo de perfil HTML4 : el atributo de perfil en el HTML.HEADelemento puede proporcionar los datos relevantes a los usuarios; Además, las notas de la documentación que los "profile"puntos de valores de atributos a los Alpes propio perfil (ejemplo: HTML5 Perfil Elemento : documentos HTML5 utilizan el elemento junto con el los valores de enlace al perfil (ejemplo: )<head profile= "http://alps.io/profiles/microblogging">…</head>
    Linkhrefrel<link href="http://alps.io/profiles/microblogging" rel="profile" />

Mapeo HTML

La asignación de la implementación del perfil ALPS a HTML es bastante sencilla. La documentación señala algunos ejemplos válidos específicos. Primero, señala lo siguiente para aplicar descriptor.iddatos ALPS a elementos HTML:

<!-- ALPS document -->
<descriptor id="abc" ... />

<!-- HTML read-only elements -->
<div class="abc">...</div>
<span class="abc">...</div>
<li class="abc">...</li>
<p class="abc">...</p>

<!-- HTML state transition elements -->
<input type="text" class="abc" />
<a href="..." class="abc" />
<img src="..." class="abc" />

Como puede ver, al indicar el ID del descriptor de esta manera, puede utilizarlo como clases en múltiples elementos. Cuando se invoca de esta manera, transforma el descriptor.iden una clase a la que se puede hacer referencia cuando corresponda. La documentación también señala que puede utilizar la descriptor.namepropiedad para crear una clase que llame al nombre en su lugar, de la siguiente manera:

<!-- ALPS document -->
<descriptor id="abc" name="xyz" ... />
<descriptor id="abc2" name="xyz" ... />

<!-- HTML read-only elements -->
<div class="xyz" data-alpsid="abc">...</div>
  <span class="xyz" data-alpsid="abc2">...</div>
</div>

<!-- HTML state transition elements -->
<input type="text" class="xyz" data-alpsid="abc2"/>
<a href="..." class="xyz" data-alpsid="abc"/>

El mapeo que aplica ALPS es relativamente simple, pero debe ceñirse a una convención consistente. Siempre que esta convención sea la misma en toda la definición, se mantendrá la misma justificación de contexto con bandas, dejando en claro qué hace la API y dónde residen esos atributos de perfil en la definición.

Una aplicación de ejemplo

Veamos un ejemplo sencillo. Este es un ejemplo de perfil de cuenta de usuario en la documentación y representa la claridad que ALPS puede ofrecer.

<alps>
  <link rel="self" href="http://alps.io/profiles/useraccount" /> <1>

  <!-- data elements --> <2>
  <descriptor id="user" type="semantic" />
  <descriptor id="accessCode" type="semantic" />
  <descriptor id="givenName" type="semantic" />
  <descriptor id="familyName" type="semantic" />
  <descriptor id="email" type="semantic" />
  <descriptor id="telephone" type="semantic" />

  <!-- transitions --> <3>
  <descriptor id="list" type="safe" /> <4>
  <descriptor id="detail" type="safe" /> <5>
  <descriptor id="login-link" type="safe" name="login" /> <6>
  <descriptor id="login-form" type="unsafe" name="login" /> <7>
  <descriptor id="create-link" type="safe" name="create"/> <7>
  <descriptor id="create-form" type="unsafe" "name="create/> <8>
  <descriptor id="update-link" type="safe" name="update"/> <9>
  <descriptor id="update-form" type="idempotent" name="update" /> <10>
  <descriptor id="remove-link" type="safe" name="remove" /> <11>
  <descriptor id="remove-form" type="idempotent" name="remove" /> <12>

</alps>

Primero, tenemos la directiva sobre dónde se puede encontrar el perfil aquí:

  <link rel="self" href="http://alps.io/profiles/useraccount" /> <1>

A partir de aquí, comenzamos a enunciar los elementos de datos:

<!-- data elements --> <2>
<descriptor id="user" type="semantic" /> <descriptor id="accessCode" type="semantic" /> <descriptor id="givenName" type="semantic" /> <descriptor id="familyName" type="semantic" /> <descriptor id="email" type="semantic" /> <descriptor id="telephone" type="semantic" />

Tenga en cuenta que el tipo aquí se indica como "semantic"En ALPS, se pueden utilizar cuatro valores fundamentales: seguro, inseguro, idempotente y semántico. Hemos discutido estos matices en detalle anteriormente en las API nórdicas , por lo que le sugerimos que lea ese artículo si necesita actualizar su comprensión de la idempotencia. En resumen, algo es idempotente si da el mismo resultado cada vez, independientemente del cambio (como eliminar siempre un elemento, independientemente de lo que invoque la solicitud).

Aquí, creamos algunos elementos de datos: useres bastante obvio el ID de usuario, accessCodees el código utilizado para iniciar sesión, etc. Ahora que tenemos estos elementos de datos, debemos indicar las transiciones que actuarán sobre ellos:

  <!-- transitions --> <3>
  <descriptor id="list" type="safe" /> <4>
  <descriptor id="detail" type="safe" /> <5>
  <descriptor id="login-link" type="safe" name="login" /> <6>
  <descriptor id="login-form" type="unsafe" name="login" /> <7>
  <descriptor id="create-link" type="safe" name="create"/> <7>
  <descriptor id="create-form" type="unsafe" "name="create/> <8>
  <descriptor id="update-link" type="safe" name="update"/> <9>
  <descriptor id="update-form" type="idempotent" name="update" /> <10>
  <descriptor id="remove-link" type="safe" name="remove" /> <11>
  <descriptor id="remove-form" type="idempotent" name="remove" /> <12>

Aquí, hemos establecido una variedad de funciones, cada una de las cuales puede actuar sobre los elementos de datos. Tenga en cuenta que el servidor selecciona qué elementos de datos se pueden usar y qué transiciones se pueden realizar contra ellos. Una vez más, ALPS define el "qué", no el "cómo". Podemos ver en esta implementación simple que cualquier servicio que utilice este perfil usará los mismos elementos de datos y transiciones. Este es el poder de ALPS, un formato de datos portátil y fácil de entender para comprender las funciones contextuales de la base de código API.

La utilidad unificada

Así que todo esto está muy bien, pero uno puede preguntarse cuál es realmente el beneficio práctico de utilizar tal definición. Ingrese a la utilidad unificada ALPS. Una versión relativamente nueva, ALPS Unified Utility es una utilidad simple que toma documentos válidos de descripción de ALPS y los convierte en documentos de definición de API. El anuncio de lanzamiento señala una amplia variedad de posibles tipos de documentos, como ProtoBuf, AsyncAPI, OpenAPI y más. En esencia, la Utilidad Unificada es un paso para tomar la definición de "qué" y convertirla en el "cómo".

Un gran cambio en la forma de pensar que esto permite es lo que a Amundsen le gusta llamar el diseño primero . La idea es diseñar la API en torno a sus elementos y luego averiguar la implementación real de esos elementos más adelante. Con demasiada frecuencia, el espacio de la API lo invierte un poco: hay una idea general de lo que debería ser el producto final, pero la salida está determinada en gran medida por lo que toma la forma del código generado. En este nuevo enfoque, Amundsen sugiere crear la definición de ALPS y dejar que la API se construya por sí misma.

Si bien esta herramienta está todavía en su infancia, parece prometedora. La idea de construir alrededor del diseño primero ha sido un proceso de pensamiento común en los últimos años, por lo que ver un formato de descripción tomar esto de frente es interesante. Aún está por verse si hará o no lo que promete, pero si realmente lo cumple, podría hacer que el desarrollo sea más rápido, más fácil y más centrado en el diseño (no en el código).

Conclusión

ALPS no es una solución perfecta; habrá quienes lo encontrarán demasiado simplificado, y su dependencia de las definiciones entre el tipo de datos o la transición puede parecer demasiado simple para representar interacciones complejas. Sin embargo, recuerde que la idea es explicar el "qué", no el "cómo"; para ese propósito limitado, se cumple bien, incluso si esa entrega está necesariamente limitada por su propio alcance. Será interesante ver qué sucede con ALPS Unified Utility, y si el proyecto continúa en una dirección sólida, podría ser un competidor para la creación de API en un futuro cercano.

¿Qué opinas de ALPS? ¿Crees que es lo suficientemente potente para interacciones complejas? ¡Háganos saber en los comentarios a continuación!

Publicar un comentario

0 Comentarios