"Las API públicas son para siempre: ¿solo una oportunidad para hacerlo bien"?

En un libro de SO acabo de leer que "las API públicas son para siempre: solo una oportunidad para hacerlo bien" ¿Es verdad? ¿Es aplicable solo en las API de sistemas operativos u otras API también? Por ejemplo, ¿será esto cierto para las API de aplicaciones de Android como Tasker, Locale y Pushover?

En general, es cierto para cualquier API pública, sí. Una vez que exponga una API al público y las personas comiencen a construir aplicaciones que dependen de esa API, se vuelve extremadamente difícil cambiar la API porque hacerlo romperá todas esas aplicaciones. Eso tiende a ser un problema técnico difícil y un problema político difícil.

Por supuesto, es posible cambiar una API pública. Sucede, por ejemplo, que los proyectos depricarán una API en una versión, introducirán una nueva API y luego eliminarán la antigua API en alguna versión futura. Pero eso supone que cada aplicación (importante) que usa la API anterior se reescribirá para usar la nueva API antes de que se elimine la API anterior. Eso a menudo lleva varios años. Y eso significa que el propietario de la API pública está imponiendo un costo en todos los demás proyectos que consumen la API. Como generalmente hay muchos más consumidores de una API, esos consumidores tienden a ser un lobby político relativamente poderoso.

El autor de la cita es Joshua Bloch, la declaración es de su artículo de diseño de API Bumper-Sticker :

Las API públicas, como los diamantes, son para siempre. Tienes una oportunidad de hacerlo bien, así que da lo mejor de ti.

Para obtener más detalles al respecto, el autor remite a los lectores a la presentación de su sesión de conferencia, "Cómo diseñar una buena API y por qué es importante" . Diapositiva ¿Por qué es importante para usted el diseño de API ? Establece claramente que esto es relevante para cualquier actividad de programación (sistemas operativos o no, no importa al autor):

• Si programa, es un diseñador de API

  • Un buen código es modular: cada módulo tiene una API

• Los módulos útiles tienden a reutilizarse

  • Una vez que el módulo tiene usuarios, no puede cambiar la API a voluntad
  • Los buenos módulos reutilizables son activos corporativos.

• Pensar en términos de API mejora la calidad del código

La conclusión de la diapositiva también enfatiza esto como un enfoque general:

• El diseño API es un oficio noble y gratificante

  • Mejora la cantidad de programadores, usuarios finales, empresas ...

Las API siempre cambian, de lo contrario, ¿cuál sería el punto de actualización del sistema? ¿Solo cambios internos?

Cada versión del sistema trae nuevas API, las API antiguas se vuelven obsoletas y las API obsoletas desaparecen.

El cambio de API solo tiene que ser muy cuidadoso tanto técnicamente como en términos de comunicación.

Mi opinión sería que una vez lanzada, esa 'versión' de la API es para siempre, pero puede desaprobarla lanzando una API '2.0' (hay varios ejemplos en los que esto está sucediendo; actualmente, puedo pensar en Strava que ha lanzado una versión 2.0 de una API para el desarrollo contra el consumo de sus servicios).

El problema es admitir esa API original hasta el infinito ... Supongo que depende del uso de la API anterior y del valor que esos consumidores de API tienen para usted.

Volviendo a 'los viejos tiempos' de Windows 3.xy 9x, etc., una vez lanzados, esas API del sistema operativo estaban listas y configuradas. Ahora, las actualizaciones del sistema operativo se envían todo el tiempo, por lo que se pueden lanzar nuevas API, pero creo que mientras ejecute un sabor de sistema operativo particular (versión principal), esas API solo se agregarán, nunca se eliminarán ... puede que no Sin embargo, este será el caso para el 'próximo' lanzamiento principal.

Hmm, tal vez me desvié de la intención de la pregunta original.

Depende de qué tipo de API sea (y estoy asumiendo cambios importantes, de lo contrario, la declaración obviamente no es cierta).

Si la persona que llama puede elegir qué versión está usando (por ejemplo, con bibliotecas / marcos que se incluyen con la aplicación de llamada), cambiar la API no es un gran problema, pero sigue siendo malo para la reputación del software. A la gente le gusta actualizar sin problemas.

Por otro lado, cuando las personas no pueden seguir usando la versión anterior de la API (como con un servicio en línea, o cosas como un navegador o sistema operativo donde ejecutar versiones antiguas es muy indeseable), cambiar las API de una manera incompatible es muy malo de hecho, ya que romperá todo el software que lo usa y no se actualiza también. Esto impone un costo de mantenimiento a los desarrolladores, y lo odiarán por ello. Y el software que no se mantiene y las interrupciones también se reflejarán mal en usted.

Por otro lado, hay al menos un proveedor de API que constantemente introduce cambios importantes en la API y de todos modos es ridículamente exitoso: Facebook. Pero sí gestionan los cambios con mucho cuidado: hay una política publicada , los cambios de última hora se anuncian y explican al menos 90 días antes, y los desarrolladores pueden optar por activarlos temprano dentro de ese plazo.

Si tiene la previsión de incluir un número de versión en la propia API. Ya sea en la llamada de conexión / inicialización o, en algún lugar cerca del comienzo de la lista de parámetros en cada llamada, su API puede evolucionar y mutar con el tiempo sin interrumpir a los clientes existentes.

Aunque todo lo que hacemos es hacerlos mejores de una vez, pero dado que el cambio de tiempo y la mejora llegan, a veces necesitamos actualizar la información, como lo han estado haciendo muchos proveedores gigantes (como la actualización de Facebook, una de las principales recurriendo a oAuth y varias principales, pero a lo más posible, todo viene con una mejora, por lo que no hay cambios frecuentes.

Cada vez que lanza cualquier tipo de protocolo de comunicaciones, que obviamente incluiría una API, tiene una oportunidad de hacerlo correctamente en el sentido de que el protocolo / interfaz debe ser compatible con versiones anteriores y extensible.

Esto le permite agregar nuevas funcionalidades y lanzar nuevas versiones sin tener que preocuparse por romper las personas que usan versiones anteriores. Nunca en el mundo del software vas a tener una situación en la que puedas tener una transición difícil en un momento determinado, y todos abandonen la versión anterior y comiencen a usar la nueva.