Header Ads Widget

Ticker

6/recent/ticker-posts

¿Qué es el modelo de madurez de Richardson?


 Si bien la mayoría de los desarrolladores conocen a Roy Fielding y REST, es posible que menos conozcan el modelo de madurez de Richardson. Aunque el modelo de madurez de Richardson a menudo se considera más esotérico en comparación con sus compatriotas más famosos, puede servir como un objetivo para lograr API realmente completas y útiles .

Hoy, vamos a discutir el Modelo de Madurez de Richardson diseñado por Leonard Richardson . El modelo identifica tres capas: URI , métodos HTTP y HATEOAS (hipermedia) para determinar la madurez de un servicio. Ampliaremos estos niveles, lo que implican y en qué resultan. Analizaremos el modelo de madurez de Richardson en el contexto de REST e identificaremos cómo el modelo de madurez de Richardson puede ayudar a guiar el proceso de desarrollo de API.

Nivel 0 - El pantano de POX

Es posible que necesite más que jabón para limpiar el pantano de la viruela

El modelo de madurez de Richardson no comienza en el nivel 1, sino en el nivel 0, el "pantano de la viruela". POX en este caso significa Plain Old XML y representa la funcionalidad más básica que se espera de una API que ingresa al Modelo de Madurez de Richardson. En este nivel, HTTP se utiliza como mecanismo de transporte para cada interacción remota, pero estas interacciones no utilizan los mecanismos inherentes a la web. HTTP sirve solo como un mecanismo básico de tunelización.

En este nivel, toda la interacción de API es esencialmente RPC , una conversación XML de ida y vuelta en la que cada solicitud y respuesta no es más que un fragmento de código. Esto puede ser útil en algunos casos, seguramente, pero incluso en SOAP , la penúltima solución centrada en POX, cada iteración y evolución no es más que envolver el proceso HTTP en un sobre complicado.

Nivel 1 - Recursos

Utilizar recursos para comenzar el proceso de maduración de la API

Las conversaciones XML funcionan en algunos escenarios, pero no son ideales para las tareas complejas que se requieren en las interacciones y ofertas de API modernas. Por un lado, POX es ineficiente , a menudo transfiere texto superfluo. En segundo lugar, al comunicarse a través de XML, está complicando demasiado lo que debería ser una comunicación simple, eficiente y concisa.

Nuestro primer paso para corregir estos problemas es salir del pantano de POX utilizando recursos . Los recursos permiten que las solicitudes se envíen al recurso específico en cuestión, en lugar de simplemente intercambiar datos entre cada punto final de servicio individual. Si bien esto parece una pequeña diferencia, en términos de función, es un cambio radical completo.

En POX, una función mal definida simplemente se llama desde un cuerpo grande, un miasma similar al éter de recursos recopilados y posibles puntos de resolución, y luego esta función se define con más argumentos complejos. Al adoptar recursos en lugar de cuerpos XML para la comunicación, estamos estableciendo un tipo de identidad de objeto , llamando a un objeto en particular y pasándole argumentos que están específicamente relacionados solo con su función y forma.

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

Nivel 2 - Verbos HTTP

Uso correcto del verbo HTTP

Ahora que nos hemos movido hacia los recursos, podemos comenzar a ver cómo interactuamos con esos recursos. En el enfoque de POX, la verborrea a menudo no importa específicamente. POSThace lo que POSThace, pero GETen muchos casos puede funcionar de la misma manera, lo que da como resultado una API que a menudo entrega los mismos datos para duplicar verbos. En el nivel 0 y el nivel 1, estos verbos sirven como un mecanismo de túnel para su solicitud; en esos niveles, esto está bien, ya que todo lo que la API realmente está haciendo es conversar en XML con XML.

Sin embargo, el problema es que la verborrea es diferente por una razón. Cada verbo - GETPOSTPUTDELETE, etc - hace algo muy específico, y estas funciones entregan a menudo totalmente diferentes conjuntos de resultados cuando se abordan adecuadamente - la falta de apalancamiento HTTP verbos por sus medios Usos correctos que usted está perdiendo una gran cantidad de funcionalidad potencial de ningún razón.

Como buen ejemplo, ambos POSTGETen el enfoque de POX darán como resultado el mismo retorno GET; sin embargo, se define como una operación segura, que abre un montón de funcionalidades. Una de esas funciones es el almacenamiento en caché , que se puede utilizar con gran efecto para reducir la cantidad de procesamiento que necesita la API, y un aumento en la eficiencia del tránsito al eliminar la necesidad de responder a solicitudes que solo generarán el mismo resultado.

Todo eso se pierde, por supuesto, sin diseñar sus recursos específicamente en torno a la verborrea y la respuesta esperada. Al diferenciar el apalancamiento a través del diseño en el nivel 2, podemos aprovechar al máximo dichos beneficios.

Para obtener más información sobre la verborrea HTTP, lea: Diseño de API evolucionables para la Web: Interacción

Nivel 3 - Controles hipermedia

HATEOAS ofrece más enlaces e información

Para muchos desarrolladores, el nivel 2 es "suficientemente bueno". La verborrea adecuada y una reducción en la dependencia de la charla XML parece dar como resultado una API que está básicamente en un estado utilizable y, como tal, es donde muchos desarrolladores se sienten cómodos con detenerse. Desafortunadamente, esto no es todo el objetivo de este ejercicio: el paso final, el nivel 3, otorga ciertos beneficios que no deben ignorarse.

El nivel 3 implementa hipermedia , que puede usarse con gran efecto para extender la funcionalidad de una API a nuevos niveles. Al implementar HATEOAS (hipertexto como motor del estado de la aplicación), podemos hacer que la API responda a las solicitudes con información adicional y vincular recursos para obtener interacciones más ricas. Estos enlaces pueden hacer que la experiencia del usuario sea mucho más rica y pueden crear una red de funcionalidades que resulten en una más poderosa, más eficiente y más útil.

La utilización de hipermedia también ofrece la capacidad de actualizar esquemas de URI sin interrumpir a los clientes, lo que permite una mayor libertad para el cambio de desarrollo en el back-end. Este no es el caso antes del nivel 3, pero los beneficios no terminan ahí. El simple hecho es que una API que no utiliza Hypermedia está funcionando en su nivel más básico y menos útil: los fundamentos pueden estar disponibles, pero la API es autolimitante en extremo.

Relacionado: Máquina de estado REST revisada

Desarrollo de guías del modelo de madurez de Richardson

Más allá de las razones mencionadas anteriormente, existe una razón aún mayor para adoptar el modelo de madurez de Richardson hasta el nivel 3. Según Roy Fielding, el creador del concepto de diseño RESTful, Hypermedia es un requisito previo para el verdadero REST. Como tal, alcanzar el tercer nivel final del Modelo de Madurez de Richardson puede verse como un objetivo para los equipos de desarrollo que desean una verdadera conclusión RESTful .

Dicho todo esto, el nivel final del Modelo de Madurez de Richardson no es el final absoluto para el diseño de API. REST es muy útil, pero hay algunos casos en los que SOAP tiene sentido , y en ese caso. Incluso en esos casos, de los cuales hay pocos, el modelo de madurez de Richardson de nivel 2 sigue siendo un buen objetivo a alcanzar, ya que es allí donde una API pasa a depender de los recursos en lugar de los cuerpos XML y los puntos finales indiferenciados masivos.

Aquí, podemos ver dónde brilla realmente el modelo de madurez de Richardson. Sí, sus niveles finales darán como resultado un resultado RESTful, pero en última instancia, el modelo de madurez de Richardson es un gran sistema mediante el cual se puede medir la madurez de una implementación. Dado que cada requisito de madurez de su implementación fluctúa en gran medida debido a los requisitos del usuario, el modelo de madurez de Richardson se puede utilizar como una especie de estructura mediante la cual el desarrollo puede guiarse hacia un resultado más completo y maduro, independientemente de los elementos fundamentales de la propia API.

También agrega estructura para el desarrollo colaborativo. Cualquier desarrollo comenzará naturalmente como menos maduro y evolucionará hacia más maduro. Guiar el diseño de API únicamente por características o motivos económicos sin una estructura establecida puede generar problemas. Por tanto, el desarrollo técnico debe ser guiado y estructurado con un objetivo en mente.

Más importantes que estos elementos son las estructuras que dictan fundamentalmente si la API es RESTful o no, si utiliza recursos o no y si respeta la verborrea estandarizada. El modelo de madurez de Richardson puede funcionar como un sistema para garantizar el cumplimiento y promover la madurez a lo largo del ciclo de vida del desarrollo .

Un camino hacia la realización de API

Ahh, fuera del pantano. Esto se ve mucho mejor.

El modelo de madurez de Richardson es una forma visual de medir la competencia de su API. En este artículo analizamos cada capa: XML antiguo simple, recursos, verbos HTTP e hipermedia. Al igual que la Jerarquía de Maslow , el viaje hacia la realización es un ascenso; a medida que su API avanza, se cumple más.

Si bien el modelo de madurez de Richardson no es el único modelo de desarrollo que se ofrece en el panorama de API, es difícil argumentar contra sus filosofías centrales. El simple hecho de que su objetivo final, la integración de Hypermedia, sea considerado por el propio Roy Fielding como un requisito previo para el diseño REST debería hacer que cualquiera que desarrolle una aplicación REST se dé cuenta.

Además, incluso al ignorar sus atributos RESTful, el Modelo de Madurez de Richardson ofrece un objetivo para el desarrollo que dará como resultado API más grandes y más diseñadas que responden de una manera más natural, efectiva y poderosa.

Recursos adicionales

  • Modelo de madurez de Richardson: pasos hacia la gloria de REST
  • Modelo de madurez de Richardson
  • Tercer acto: la heurística de la madurez

Publicar un comentario

0 Comentarios