Header Ads Widget

Ticker

6/recent/ticker-posts

Máquina de estado REST revisada


En los meses posteriores a la publicación de Designing a True REST State Machine y la charla en la que se basó , ha habido bastante discusión y las preguntas planteadas deberían abordarse. Si bien se podría responder a cada uno de manera individual, tal vez les resulte más útil escribir todo en una publicación de blog. Esta es esa publicación de blog.

La discusión y las preguntas se referían principalmente a los cuatro conceptos erróneos de REST que se trataron en el artículo y la charla. Estos conceptos erróneos son:

  1. REST es solo CRUD
  2. Algunas construcciones de URI son más RESTful que otras
  3. Las API REST deben tener versiones
  4. Hypermedia es opcional para las API REST

Cada concepto erróneo se desarrollará a continuación, lo que con suerte responderá las preguntas y proporcionará un poco más de claridad.

REST y CRUD

Comencemos por abordar el primer concepto erróneo de REST presentado en la charla y el artículo: que las API RESTful deben diseñarse según el principio CRUD . Obviamente, este fue un tema que no recibió suficiente tiempo o atención, lo que provocó cierta confusión y malentendidos.

Este tema parece haber tocado la fibra sensible de Nic Nilov en particular, quien escribe :

Los nombres de los métodos HTTP no son sinónimos de operaciones CRUD por al menos una simple razón histórica de estar establecidos dentro (en ese momento) en dominios de la computación bastante separados. Semánticamente, no son tan diferentes como la medida a la que estás tratando de estirarte.

Nic Nilov

Hay una diferencia entre HTTP y REST. El objetivo de este tema es que no debe modelar su API REST según el principio CRUD. Los métodos HTTP se usaron simplemente como un ejemplo de por qué CRUD no solo era limitante, sino que también estaba equivocado.

En la disertación de Fielding (capítulo 5.2.1.2) , escribe:

Los componentes REST realizan acciones en un recurso utilizando una representación para capturar el estado actual o previsto de ese recurso y transfiriendo esa representación entre componentes.

Roy Fielding

El punto, que tal vez no quedó lo suficientemente claro, fue que en las API RESTful bien diseñadas, el método HTTP preciso utilizado por una operación es un detalle de implementación poco interesante. Es casi, pero no del todo, tan poco interesante como la forma del URI de una operación determinada.

En la publicación del blog Está bien usar POST , Fielding escribe:

Busque en mi disertación y no encontrará ninguna mención de CRUD o POST. La única mención de PUT es con respecto a la falta de almacenamiento en caché de escritura diferida de HTTP. La razón principal de mi falta de especificidad es que los métodos definidos por HTTP son parte de la definición de la arquitectura de la Web, no del estilo arquitectónico REST.

Roy Fielding

Diseñar su API después de CRUD lo limita a solo crear, leer, actualizar y eliminar. Punto final. CRUD es un límite artificial que usted o algún marco puede imponer a su API que simplemente no existe en HTTP o REST. Su API no debería ser simplemente una envoltura delgada alrededor de su base de datos. Como tuitea Mike Amundsen :

Recuerde, al diseñar su WebAPI, su modelo de datos no es su modelo de objetos, no es su modelo de recursos, no es su modelo de mensaje.

Derek Comartin amplía este principio en una publicación de blog . Si desea que su API devuelva algo que no sea una representación del Cliente después de una CreateCustomersolicitud, no debe dejar que los límites de CRUD lo inhiban . ¡Cada solicitud a cada recurso puede responder con lo que quiera! Limitar la API a CRUD elimina esta flexibilidad, lo que hace que muchas API se vean afectadas por problemas de rendimiento.

Lea también: 7 tendencias de diseño de API en crecimiento

Sobre el uso POST

Y esto se corresponde perfectamente con el uso y la versatilidad de POST, de los cuales Nic tiene lo siguiente que decir:

El protocolo SOAP que mencionaste usa POST en todo momento no debido a una versatilidad sin precedentes del método. Eso se debe al mero hecho de que PUT ni siquiera existía hasta aproximadamente el mismo tiempo en que se puso a disposición la especificación SOAP. PATCH se convirtió en estándar diez años más tarde.

Esto es algo cierto, pero no del todo. PATCHen realidad se definió en la primera especificación HTTP / 1.1 ( RFC 2068 sección 19.6.1.1 ), pero se eliminó en la actualización dos años después (la querida RFC 2616 ). De cualquier manera, incluso si SOAP se diseñó hoy, el único método HTTP que podría transmitir la funcionalidad y la semántica requeridas del protocolo es POST.

Volviendo a la publicación del blog de Fielding sobre el POSTmétodo, tiene esto que decir:

POST tiene muchos propósitos útiles en HTTP, incluido el propósito general de "no vale la pena estandarizar esta acción".

Roy Fielding

Basado en esto y en la tesis de Fielding, creo que es fácil ver que lo que importa son las transiciones de estado y cómo las modelas. Para la mayoría de las transiciones de estado, POST es simplemente el método HTTP más adecuado.

Las operaciones deben modelarse en torno a conceptos abstractos como CreateCustomerCapturePaymentCancelAccountSi la API decide utilizar PUTPOSTDELETEpara cada una de estas operaciones no es de mucha importancia, al menos no en el cliente y no al diseño de la API. Los métodos HTTP que utiliza la API son importantes solo "en el cable", es decir, en términos de la semántica de su protocolo, si son idempotentes, cómo afectan el almacenamiento en caché, si son seguros o inseguros, etc.

Entonces, por todos los medios, haga su tarea sobre cómo funciona cada método HTTP, pero no limite el diseño de su API a CRUD.

URI RESTful

Sobre el segundo concepto erróneo, que algunos URI son más RESTful que otros, Nic Nilov no está de acuerdo y argumenta que la restricción de interfaz uniforme de REST significa exactamente eso: la forma del URI y cuán amigable para los humanos es importante.

Sin embargo, la restricción de interfaz uniforme de REST no dice nada sobre el significado de un URI o cómo un cliente debe comprender sus partes individuales para construirlo correctamente. Si desea que un cliente construya un URI, puede usar Plantillas de URI ( RFC 6570 ), pero codificar URI en su documentación y, por lo tanto, también en todos los clientes de su API, es una clara violación de la restricción REST que debe ser hipermedia. el motor del estado de la aplicación :

Se debe ingresar una API REST sin conocimiento previo más allá del URI inicial (marcador) y un conjunto de tipos de medios estandarizados que son apropiados para la audiencia prevista (es decir, se espera que los comprenda cualquier cliente que pueda usar la API).

Roy Fielding

Está bien hacer que los URI estén al frente y al centro y codificados de forma rígida tanto en la documentación como en los clientes de su API, pero eso hace que la API no cumpla con REST ya que no está impulsada por hipermedia. Si esa es una compensación que vale la pena aceptar, hágalo. Simplemente no afirme que su API es RESTful.

Control de versiones

El tercer concepto erróneo, que las API REST deberían tener versiones, era un tema con tantas buenas preguntas que merecían una respuesta en profundidad que hemos publicado un artículo completo dedicado al control de versiones de API web . Podría proporcionar nuevas ideas sobre cómo abordar los cambios en sus API web a través de una estrategia de cambio en lugar de una estrategia de control de versiones .

Hipermedia como motor del estado de la aplicación

El cuarto y último error, que los hipermedia son opcionales, fue, como era de esperar, el tema que provocó más discusiones y preguntas.

La condicionalidad de las operaciones

Kevin y Richard Henderson se preguntan sobre la condicionalidad de las operaciones y si el hecho de que no siempre estén disponibles romperá al cliente.

Primero, es obvio que las operaciones que un cliente está diseñado para comprender son, en muchos sentidos, estáticas. Cuán estática es la comprensión de un cliente de una API depende de cuán ricos sean tanto el cliente como la API.

Es posible con JSON-LD e Hydra usar subclases de operaciones para hacer que un cliente comprenda una superclase para que también realice la acción de una subclase.

Lo que HATEOAS significa no es que la totalidad de las operaciones disponibles sea altamente dinámica, sino que cada operación es condicional dado el estado actual de un recurso.

La condicionalidad de las operaciones es una de las grandes fortalezas de los hipermedia. Las operaciones que son efímeras suelen ser la regla, más que una excepción, de las API impulsadas por hipermedia.

Dado que las operaciones disponibles se entregan dinámicamente en todas y cada una de las respuestas, pueden variar según cualquier condición que elija el servidor. Todo, desde la autorización y el estado de los sistemas de terceros hasta el clima y la fase de la luna, puede usarse como condiciones que afectan la disponibilidad de ciertas operaciones. Para los dispositivos de IoT, esto último no es una broma, sino una realidad .

Un cliente no puede saber qué operaciones son legales en el estado actual del recurso sin duplicar la máquina de estado del servidor. Al variar las operaciones que se devuelven en el estado dado del recurso, simplifica la administración del estado del cliente. Solo necesita reaccionar a qué operaciones están disponibles en un momento dado y actuar sobre ellas.

Sin hipermedia, los clientes tienen una gestión de estado codificada de forma rígida que es de naturaleza serial.

Al desacoplar la respuesta de la solicitud y al permitir que el servidor comunique dinámicamente al cliente qué operaciones están disponibles en un momento dado, el cliente puede cambiarse de ser serial, codificado y tener una administración de estado compleja a una más simple, más flexible y paradigma de UI reactiva.

Los clientes impulsados ​​por hipermedia están menos acoplados y son más flexibles y reactivos.

El papel de los hipermedia en REST

Nic Nilov señala que el hipermedia es ortogonal a REST y que puede tener hipermedia en cualquier tipo de API. También cree que el hipermedia es una parte opcional de REST, porque agrega complejidad y, por lo tanto, debe estar justificado.

Como la charla y el artículo señalan que los hipermedia tienen más de 70 años, es obvio que existió mucho antes de REST. Por lo tanto, puede tener hipermedia sin REST; Se dan muchos ejemplos de esto en la breve lección de historia proporcionada.

Sin embargo, no es al revés. Hypermedia es un requisito claro en REST y no opcional. Si crea una API web que no está impulsada por hipermedia, simplemente no es RESTful. Fin de la discusión. Fielding definió qué es y qué no es REST; su definición no está sujeta a debate:

“Hypermedia como motor del estado de la aplicación” es una restricción REST. No es una opción. No es un ideal. El hipermedia es una limitación. Como en, lo haces o no estás haciendo REST.

Roy Fielding

Nic continúa diciendo que REST es más adecuado para software de larga duración. Esto es correcto. Para ser más precisos, REST es un estilo arquitectónico que es principalmente beneficioso para sistemas distribuidos de larga duración y grandes (escala web). Eso no hace que REST no sea apto para sistemas pequeños y de corta duración, solo significa que estos sistemas no obtendrán todos los beneficios de REST.

Si controla tanto el cliente como el servidor y puede cambiar ambos simultáneamente, la compatibilidad con versiones anteriores no es un problema y los hipermedia simplemente introducirían gastos generales. Para tales API, gRPC o algo similar podría ser una mejor opción .

Sin embargo, si crea una API web de cara al público con muchos integradores independientes que escriben su propio cliente, la API está destinada a vivir más de un par de años y la API consta de muchos microservicios que cada uno ofrece una pequeña parte del la totalidad de la superficie de la API o se distribuye de otras formas, REST podría ser una excelente opción. REST tiene una mayor inversión inicial, principalmente en conocimiento, pero con el tiempo, es probable que valga la pena.

Nombres e identificadores

Richard Henderson cree que hay un problema del huevo y la gallina con HATEOAS y se pregunta quién consume los enlaces y cómo es posible conocer el significado de cada enlace.

Los enlaces y las operaciones son consumidos por máquinas que entienden su significado porque están estandarizados. Estos nombres generalmente se definen en documentación legible por humanos, como la que acompaña a la API, el Registro de relaciones de enlaces de IANA o similar. Ejemplos de algunos nombres de relaciones de enlace estandarizados por IANA son authordescribesnext.

Una forma más distribuida y flexible de crear nombres es a través de URI. Dado que los URI son identificadores únicos a nivel mundial que cualquier persona puede crear, es fácil crear su propio conjunto de "nombres" que identifiquen los enlaces y las operaciones dentro de su vocabulario hipermedia.

Lo bueno de los URI es que pueden ser URL, lo que significa que no se pueden hacer referencia a ellos. Puede pegar la URL en un navegador y ver una página web correspondiente. Si la página web contiene documentación sobre lo que significa el “nombre” o la “cosa” que identifica, tiene algo bastante poderoso, pero simple, a su disposición.

Este sistema de URL que identifican "cosas" que están documentadas en la propia URL es sobre lo que se basa schema.org . Allí puede encontrar una gran cantidad de nombres que puede usar en su API, como authorerroridentifier.

A medida que aumenta el uso de schema.org al ser el vocabulario acordado para las iniciativas de datos estructurados de Google, Microsoft, Yahoo y Yandex para sus motores de búsqueda, su uso seguramente también aumentará para las API. Con algunos vocabularios estandarizados y algunos formatos hipermedia estandarizados que los soportan (como Hydra ), los clientes pueden dejar de ser copos de nieve únicos acoplados a API específicas y, en su lugar, moverse en la dirección de la generalidad y la reutilización.

El futuro de la hipermedia

Nic Nilov termina la discusión diciendo que HATEOAS no es el primer intento de hacer que los recursos sean detectables y que los anteriores realmente no funcionaron en masa. HATEOAS, como otros antes, requiere un compromiso con la complejidad, argumenta, algo con lo que la mayoría de las empresas no se sienten muy cómodas.

Esto es algo con lo que es difícil no estar de acuerdo. Pero hay esperanza. La programación funcional se consideraba agradable en teoría, pero imposible en la práctica hasta hace aproximadamente 10 años. Alrededor de ese tiempo, ocurrió una ráfaga de actividad relacionada con la programación funcional en casi todos los lenguajes de programación populares. C # 3.0 obtuvo expresiones lambda, Ruby obtuvo una sintaxis lambda mejorada y bloqueó variables locales, Objective C obtuvo bloques, C ++ obtuvo lambdas, etc.

De repente, después de 50 años de ser un concepto teórico, académico, “inútil en la práctica”, la programación funcional era tan práctica y bien comprendida por los desarrolladores como los bucles y las ifdeclaraciones.

Ahora la programación funcional incluso está demostrando ser la solución al fracaso de la ley de Moore . Al no compartir estado, tener inmutabilidad y funciones como ciudadanos de primera clase en un lenguaje de programación, puede paralelizar aplicaciones de una manera mucho más segura y sencilla de lo que era posible antes con abstracciones difíciles y propensas a errores como los hilos .

El lenguaje de programación de sistemas funcionales Rust es uno de los mayores testimonios de esto. Con Rust, es posible realizar una paralelización de manera segura y eficiente que es simplemente demasiado difícil de expresar y hacer de manera confiable y sin errores en la mayoría de los otros lenguajes de programación de sistemas. El óxido también es inteligente en muchos otros aspectos, pero sus propiedades funcionales son las que facilitan este poder.

Hay razones para creer que el hipermedia está en el mismo lugar que la programación funcional hace 20 años. Es difícil decir qué se requiere para que los hipermedia obtengan la misma revolución y cambio de mentalidad que la programación funcional hace 10 años, pero a través del tedioso trabajo de las personas involucradas en estandarizar formatos hipermedia, crear herramientas, escribir pautas, etc., podríamos obtener allí un día.

 

Publicar un comentario

0 Comentarios