Header Ads Widget

Ticker

6/recent/ticker-posts

¿Qué significa la ley de Hyrum para el diseño de API?

Cuando se trata del comportamiento del software, los desarrolladores a menudo confían en lo que obtienen y no necesariamente en lo que se les promete . Cuantos más desarrolladores tenga, más probable será que alguien dependa del comportamiento implícito de su API, una observación conocida como Ley de Hyrum . En este artículo, discutiremos qué significa exactamente esta observación, por qué puede ser un problema para usted y sus desarrolladores, y qué hacer al respecto.


¿Qué es la ley de Hyrum?

La Ley de Hyrum es un fenómeno en la ingeniería de software por el cual los desarrolladores dependen de todos los rasgos y comportamientos observables de una interfaz, incluso si no están definidos en el contrato. El ingeniero de Google, Hyrum Wright, describió originalmente el fenómeno, redactándolo de la siguiente manera:

"Con una cantidad suficiente de usuarios de una API,
no importa lo que prometa en el contrato: alguien dependerá de
todos los comportamientos observables de su sistema
".

En otras palabras, los desarrolladores construirán contra lo que sea que les dé, independientemente de si el contrato lo define explícitamente, lo que resulta en lo que se llama una interfaz implícita .

Por ejemplo, en un entorno del mundo real, las API REST a menudo se describen con un archivo de especificación de OpenAPI. El archivo de especificación en sí y cualquier documentación generada a partir de él deben definir qué recursos existen, qué parámetros toman y qué datos exponen. Sin embargo, esto puede omitir muchos otros rasgos importantes del comportamiento de la API, como el tamaño de la respuesta, el formato , la paginación o el rendimiento y la latencia .

La ley de las abstracciones con fugas

Antes de continuar, vale la pena mencionar que los "comportamientos observables" a los que se hace referencia en la Ley de Hyrum pueden provenir de otro fenómeno de la ingeniería de software, la Ley de abstracciones con fugas , que establece que:

"Todas las abstracciones no triviales, hasta cierto punto, tienen fugas".

Dado que las API casi siempre implican una cierta cantidad de abstracción de la complejidad de las implementaciones internas, para proporcionar una funcionalidad útil y específica, se deduce que algunos rasgos y comportamientos de las implementaciones internas en sí se filtrarán.

En otras palabras, esto significa que la interfaz implícita en la que los usuarios llegan a confiar como resultado de la Ley de Hyrum puede incorporar los rasgos y comportamientos de los sistemas internos. Volveremos a esta idea (y por qué es un problema) más adelante.

Ejemplos de la ley de Hyrum

Estos son algunos ejemplos de rasgos y comportamientos observables de los que los desarrolladores pueden llegar a depender, independientemente de si el contrato los define o no:

  1. Ordenar o no tener listas en las respuestas
  2. Tipos de archivos devueltos desde puntos finales específicos
  3. Contenido de las respuestas (p. Ej., El formato de las URL devueltas)
  4. Códigos de estado y números de referencia de mensajes de error
  5. Objetos o cargas útiles grandes o pequeños
  6. Tiempos de respuesta rápidos o lentos

¿Por qué es mala una interfaz implícita?

El problema con las interfaces implícitas es que los desarrolladores confían en ellas, como se describe en la Ley de Hyrum. Cuando los desarrolladores confían en rasgos y comportamientos que no están definidos en el contrato, se vuelve mucho más fácil para los propietarios de API introducir cambios importantes de forma accidental. En otras palabras, cada cambio que hacen en la interfaz ahora tiene el potencial de romper las aplicaciones de sus desarrolladores.

Incluso si los propietarios de API toman todas las precauciones posibles para evitar cambios importantes, todavía existe un gran error fundamental. Si los desarrolladores pueden confiar en cualquier rasgos y comportamientos que observan, cómo se supone que los propietarios de API a saber qué partes de la interfaz que pueden y no pueden cambiar? Ellos no están; en cambio, tienen que depender del razonamiento y la intuición para predecir con qué cuentan los desarrolladores.

Y ahora llegamos a otra amenaza más. Recuerde la ley de las abstracciones con fugas : los rasgos y comportamientos de la interfaz, que en sí misma suele ser una abstracción, bien pueden ser rasgos y comportamientos de los sistemas internos. En otras palabras, los desarrolladores pueden haber llegado a confiar en el funcionamiento interno de su implementación, lo que significa que ahora puede romper sus aplicaciones sin siquiera cambiar la interfaz.

Algunos podrían argumentar que nada de esto es problema de los propietarios de API: el contrato es un acuerdo de dos vías y los consumidores desarrolladores deben mantener su parte del trato, es decir, solo depender de lo que se promete explícitamente. La realidad es que los desarrolladores hacer dependen de rasgos y conductas observables, a menudo por necesidad.

"Y si puede decirle a alguien que confiaba en un comportamiento no especificado que se mueva por la arena es una decisión comercial, más que técnica". PaleCommander en Reddit

Cómo negar la ley de Hyrum

Hemos analizado qué es la Ley de Hyrum y por qué es un problema para todos los involucrados, pero ¿qué puede hacer usted, el propietario de la API, al respecto? A continuación, discutimos algunas posibles soluciones.

1. Documentación

Si los desarrolladores se basan principalmente en los rasgos y comportamientos que observan en lugar de los definidos en el contrato, eso podría ser una señal de que su contrato es demasiado vago. Después de todo, si no les dice a los desarrolladores qué esperar, ¡solo pueden seguir lo que les da su API! La documentación completa es una forma de remediar esto: al describir su API con mayor profundidad, brinda a los desarrolladores más superficie para construir de manera confiable.

A partir de nuestra lista anterior de rasgos y comportamientos implícitos, es fácil ver lo beneficioso que puede ser decirle a los desarrolladores:

  1. si ordenará o no listas en las respuestas
  2. qué tipos de archivos pueden devolver los puntos finales específicos
  3. cuál podría ser el contenido de las respuestas (por ejemplo, cómo formateará las URL)
  4. qué tan grandes o pequeños pueden ser los objetos o las cargas útiles
  5. qué tan rápido o lento podría responder su API

2. Compatibilidad de errores

Suponga que sabe que algunos desarrolladores dependen absolutamente de un rasgo o comportamiento específico de la API que tiene la intención de cambiar. Es demasiado tarde para describirlo en su documentación; aunque eso podría ayudar a los nuevos desarrolladores, es poco probable que los desarrolladores existentes revisen la documentación para ver la funcionalidad con la que ya se están integrando con éxito. En este caso, la compatibilidad de errores puede ser una solución válida.

La compatibilidad con errores es la idea de replicar a propósito el comportamiento de una versión anterior, incluso si ese comportamiento no fue intencional o no deseado. Por ejemplo, si un punto final en particular solía tardar quince segundos en responder, y una nueva revisión del backend significa que ahora tardará fracciones de segundo, podría considerar emular el retraso, en caso de que alguien dependiera de él.

3. Simulacros del caos

Si usted y sus desarrolladores tienen los recursos y la resolución, también podrían considerar una simulación del caos. Esta solución original implica diversos rasgos y comportamientos no contractuales, como la velocidad o el tamaño de respuesta, para que los desarrolladores puedan crear aplicaciones más resistentes:

“Acuñado por el arquitecto de Microsoft Gareth Jones, la simulación del caos es una virtualización de API que encarna la variabilidad a propósito. El objetivo de un simulacro de caos es permitir a los desarrolladores codificar contra todo tipo de comportamiento de API extraño y maravilloso, para que puedan estar seguros de que sus integraciones sobrevivirán en todas las circunstancias ". 7 prácticas recomendadas para las zonas de pruebas de API

Aprendiendo de la ley de Hyrum

La Ley de Hyrum es una observación astuta de un fenómeno inevitable e inconveniente en la ingeniería de software: los desarrolladores dependerán de los rasgos y comportamientos que puedan ver. Esto puede ocasionar varios problemas, que giran en torno a romper accidentalmente las aplicaciones de sus desarrolladores. Sin embargo, con algo de documentación detallada, una dosis de compatibilidad de errores y tal vez incluso una simulación del caos, puede minimizar los impactos negativos de la Ley de Hyrum.

Publicar un comentario

0 Comentarios