Header Ads Widget

Ticker

6/recent/ticker-posts

¿Su API es de grado automotriz?

 

Imagine que un usuario se ha conectado a su API y activa una solicitud, solo para recibir un mensaje de error. Ahora imagina que todo esto está sucediendo mientras viajan a 70 mph en la carretera. Para Henrik Segesten , arquitecto de dominio de nube en Volvo, asegurarse de que este tipo de cosas no suceda no es cosa de malos sueños, es parte de su rutina diaria.

Segesten y co. no puede permitirse cometer los mismos errores que los desarrolladores de API que trabajan en un complemento, dicen que el termostato Nest puede hacerlo. En lugar de causar un inconveniente menor para el usuario, el impacto potencial de las fallas en el escenario del automóvil podría poner en peligro la vida. Desde la transmisión hasta el software que alimenta la electrónica a bordo, el grado automotriz equivale a pruebas rigurosas y estándares de confiabilidad extremadamente altos.

Pero se trata de algo más que garantizar que las API de automóviles sean sólidas y estén libres de errores; después de todo, ese debería ser el objetivo de cualquier desarrollador de API. Más bien, se trata de mejorar la longevidad (algo sobre lo que estamos escribiendo extensamente actualmente) y la compatibilidad.

De inmediato, podemos ver que hay una especie de desconexión aquí: es extremadamente difícil, si es que es posible, garantizar que cada paso en el proceso de API pueda ser monitoreado con el tipo de control de calidad obsesivo que exigen los verdaderos estándares de grado automotriz. . Imagine, por ejemplo, decirles a los consumidores de API que solo pueden usar sus API si realizan toda su codificación en una MacBook Pro, producida a más tardar en 2015, con OS X 10.10.5 o superior.

Pero, como veremos a continuación, hay una serie de conceptos útiles relacionados con el grado automotriz que pueden tener mucho sentido en el contexto de cómo diseñamos y actualizamos las API.

Vea a Henrik Segesten hablar en la Cumbre de la Plataforma:

Diapositivas aquí

Pruébelo como si tuviera que ser de grado automotriz

Anteriormente hemos escrito sobre la importancia de las pruebas, tanto de sus propias API como de su documentación , pero es algo que algunos desarrolladores de API siguen pasando por alto.

Piense en algunos de los procesos por los que un automóvil y sus componentes deben pasar antes de que el último modelo salga de la línea de producción:

  • Prueba de temperaturas extremas
  • Análisis de cómo se comporta el vehículo en diferentes terrenos.
  • Advertencia adecuada cuando algo no funciona correctamente
  • Mucha redundancia incorporada

Hay una lección importante del grado automotriz para los desarrolladores de API: es muy probable que las pruebas descritas anteriormente sean mucho más completas que cualquier cosa que haya realizado con sus API ... a menos que trabaje en Volvo con Segesten, donde están tratando de establecer una arquitectura API que puede permanecer sólido durante décadas.

Mientras que "grado bancario" y "grado militar" se utilizan a menudo en relación con los materiales de seguridad y de construcción, respectivamente, el grado automotriz es un término que se define con un poco más de precisión.

Segesten describe el grado automotriz como un concepto de hardware con “una medida en el nivel de calidad de todas las partes en un automóvil ... con una vida útil esperada para todos y cada uno de los componentes, hasta cada tuerca y perno, que es igual o mayor que el esperado vida útil del coche ". Eso generalmente equivale a alrededor de 30 o 40 años.

En el contexto del desarrollo de software, necesitamos aflojar un poco esa definición. No estamos necesariamente tratando de crear una API que dure tanto tiempo como, como bromea Segesten, pensar en “los chicos y chicas pobres que necesitan volver a implementar su API en veinte años. " Destaca el hecho de que "el grado automotriz se traduce en longevidad, por lo que debe diseñar teniendo en cuenta la longevidad". En otras palabras, el hecho de que algo parezca funcionar por ahora no significa que sea la elección correcta.

Grado automotriz y preparación para el futuro

Segesten aconseja mirar hacia atrás para planificar el futuro y considerar cuáles han sido los principales impulsores del software orientado a la web y el desarrollo de API durante los últimos 30 años. Vale la pena reproducir esa lista aquí:

00:AÑOS 90AÑOS 80
JABÓNHTTPFTP
JSONCORBASMTP
XMLDCETCP / IP
PGPTelnet
X509PPP
ONC / RPC

Pero esto no significa que todos los desarrolladores de API deban evitar el desarrollo RESTful en favor de estándares que han existido durante más de 30 años. Más bien, es un argumento para garantizar que su API utilice tecnología que pueda resistir el paso del tiempo. A lo largo de su vida útil, las API típicas deberán “volver a implementarse varias veces a lo largo del camino ... porque el sistema antiguo ha muerto por alguna razón. Elija su tecnología con prudencia ".

Ahora, pensemos en los protocolos / lenguajes, etc., que se usan comúnmente en el espacio API en 2017:

  • JSON
  • DESCANSO
  • JABÓN
  • XML
  • JavaScript
  • API abierta / Swagger
  • GraphQL

Es interesante observar que, de los estándares anteriores enumerados por Segesten, solo JSON, SOAP y XML aparecen a lo largo de varias décadas. Esto no significa que solo deba considerar el uso de estos formatos de datos al crear una API. Más bien, es evidencia de que diez años no es mucho tiempo en el mundo del desarrollo de software; los desarrolladores no pueden permitirse el lujo de utilizar los lenguajes y los estándares más recientes y modernos a menos que estén bastante seguros de que tienen lo necesario para resistir el paso del tiempo. Según lo que hemos visto hasta ahora, REST parece encajar en ese proyecto .

Pero vale la pena recordar, como dice Segesten, que hay más en una API que solo la tecnología que usa; las mejores API pueden prosperar independientemente de la tecnología que las impulse.

Estos son los formatos de datos y los lenguajes de definición de API más populares que se utilizan actualmente en el espacio de API

Grado automotriz y compatibilidad con versiones anteriores

Tan importante como es preparar una API para el futuro, es igualmente importante asegurarse de que también sea compatible con versiones anteriores . Por ejemplo, ¿qué pasaría si el comprador de un automóvil desactiva todas las funciones de conectividad de un automóvil, lo usa durante diez años y luego lo vende? Cuando el próximo comprador active una función de conectividad, el automóvil consumirá las API asociadas por primera vez.

La lección aquí es que las versiones antiguas de las API nunca mueren y, inevitablemente, necesitará mantenerlas porque:

  • No puede estar seguro de que todos los usuarios migrarán a ofertas posteriores
  • Es posible que ciertos productos / hardware no puedan comunicarse con su API más reciente
  • Debe seguir siendo compatible con el hardware que se desconectará, es decir, las comunicaciones asincrónicas.

Diseñar API teniendo en cuenta la compatibilidad hacia atrás y hacia adelante desde el principio, utilizando extensibilidad, opcionalidad, etc., es mucho más fácil que tratar de administrar simultáneamente decenas de versiones diferentes ... como la gente que intenta ayudar a los usuarios con versiones de Windows que tienen décadas de antigüedad. probablemente te lo diga. De hecho, existe un caso sólido de que el control de versiones ni siquiera debería suceder con las API web.

Por último, Segesten nos recuerda que es una buena idea mantener las cosas lo más simples posible. "Si tiene que tener complejidad ... intente poner toda esa complejidad en el lado del servidor, porque puede actualizar eso todo el tiempo, pero la API nunca debería tener que actualizarse". Cuando ese hipotético automóvil de diez años que mencionamos anteriormente finalmente se conecte a una API de Volvo, debería ser más o menos bueno si realiza la mayoría de los cambios en el lado del servidor.

Lea también: Asegurar el IoT para las próximas décadas

Pensamientos finales

Como hemos visto anteriormente, en particular dada la falta de desarrolladores de la API de control tienen sobre cómo y dónde se utilizan sus productos, en realidad producir una API del automóvil grado es extremadamente difícil. Si tomamos el término al pie de la letra, es decir, si permanece válido durante 30 o 40 años, puede que no sea posible en absoluto.

Cualquier desarrollador de API experimentado sabe que hay demasiadas variables que controlar para garantizar que un servicio seguirá funcionando en 2047. Con eso en mente, sería mejor considerar emplear los principios de "grado automotriz", como:

  • Usar lenguajes y metodologías a prueba de futuro , o al menos tan a prueba de futuro como sea posible
  • Tenga estrategias de compatibilidad implementadas: ¿cómo maneja su versión sus API?
  • Mantenga las cosas simples , tanto en términos de funciones como de documentación, y realice pruebas lo más minuciosamente posible para asegurarse de que todo funcione como se espera.

La buena noticia es que, para la mayoría de nosotros, nuestros consumidores de API nunca utilizarán nuestros productos o servicios a 70 mph. Pero eso no significa que no sea una buena idea prepararse como deberían ...

Publicar un comentario

0 Comentarios