Anular una API web: ¿Mejores prácticas?

15

Finalmente, debes depreciar partes de tu API web pública. Sin embargo estoy confundido sobre cuál sería la mejor manera de hacerlo. Si tiene una gran base de aplicaciones de terceros, simplemente tirar versiones antiguas de la API parece una forma incorrecta de hacerlo, ya que casi todas las aplicaciones fallarían de la noche a la mañana. Sin embargo, no puede mantener las API antiguas disponibles para siempre, ya que puede estar desactualizada o hay cambios significativos que hacen que trabajar con ella sea imposible.

¿Cuáles son algunas de las mejores prácticas para desaprobar las API de web antiguas?

    
pregunta TheLQ 05.03.2011 - 18:28

3 respuestas

15

Parece que el póster original ya ha sido efectivo, pero desaprobó informalmente su API (todo lo que se conoce como 'API antigua'). Sin embargo, hasta que se anuncie y se notifique a los usuarios que una API está en desuso, no está en desuso formal.

La API obsoleta es una etapa de código provisional e inactiva. Son los últimos ritos. Este es el período que permite a los adoptantes / consumidores reconfigurar sus aplicaciones para una API más nueva y despedirse con cariño, haciendo las paces con la API. Algunas API pueden permanecer más tiempo que otras, pero en este punto sabemos que su tiempo no es largo.

La API eliminada es un código de funeral. No hay nada más que pueda hacer, pero está debidamente dispuesto y memorizado adecuadamente.

Muchos desarrolladores de API y servicios optan por funerales de código en lugar de realizar los últimos ritos; Sin embargo, creo que es algo arriesgado. Si se hizo algún tipo de servicio o promesa de apoyo cuando se adoptó inicialmente la API / servicio o por renovación, es posible que desee respetar ese compromiso por un período de tiempo razonable antes de realizar el funeral.

Para las bibliotecas que no son de servicio, creo que una versión principal, independientemente del período de tiempo, es probablemente un período más que aceptable y justo de compatibilidad con versiones anteriores garantizadas. Más allá de eso, depende de la influencia y el cabildeo de los usuarios para extender su vida más allá de ese período. Y no se sorprenda si de vez en cuando hay objeciones debido a que las dependientes insustituibles de terceros se atascan en el limbo y se vinculan a ciertas versiones de ciertas plataformas.

Para los servicios, sospecho que es posible que desee considerar un período de seis meses o un año, simplemente debido a la variación de quién y cómo se puede consumir un servicio, y la variación correspondiente del ciclo de desarrollo de un proyecto consumidor a otro. proyecto: muchos de los proyectos que podrían estar consumiendo su servicio podrían ser un gran diseño inicial y pueden programar un ciclo de lanzamiento de más de un año. La mayoría de las opiniones de desarrolladores desde el exterior sugerirían que aquellos con horarios largos son responsables de cumplir con los tiempos de sus ciclos, y que los proyectos que consumen ciclos largos deben adoptar un ciclo de lanzamiento más rápido, y puede ser cierto. Pero en última instancia, la fecha de eliminación es algo que tiene que negociar con los usuarios.

Una estrategia buena pero no a prueba de balas para la desaprobación puede ser cuando se anula la desaprobación, resalte el período de tiempo para la intención de eliminar, junto con una solicitud de comentarios u objeciones en un formato de encuesta de las secciones API en cuestión. Si no tiene una lista de contactos de usuarios debido a que su servicio opera con acceso [semi] anónimo, puede considerar buscar registros para usuarios frecuentes y activos y enviar la notificación al host o administrador de dominio para que la reenvíe según lo considere oportuno.

    
respondido por el JustinC 06.03.2011 - 02:22
6

La mayoría de las API web que uso (de compañías como Google, Yahoo! y Microsoft) tienen un período de "puesta de sol". Los desarrolladores están informados dentro de un tiempo razonable (por ejemplo, de 3 a 6 meses) de las funciones que se van a depreciar para darles suficiente tiempo para actualizar de antemano.

Puede agregar los detalles de los períodos de extinción en sus Términos de servicio u otra documentación para que las personas sepan cómo funciona. Esto significaría que cuando alguien decida utilizar su API, sabrá con qué horarios necesita trabajar. Por ejemplo, podría informar a las personas que necesitarán actualizar su sistema una vez al año y recibir un aviso de 4 meses para hacerlo.

También es una buena idea usar la numeración de las versiones para que pueda decir que, por ejemplo, "la versión 3 se depreciará pronto, así que asegúrese de que su código funcione con la versión 4", etc. trabajando con la versión 4, están listos para la puesta de sol.

    
respondido por el Ewan Heming 05.03.2011 - 18:49
0

Además de las respuestas existentes, debe proporcionar un reemplazo directo o un plan de migración cuando elimine algo, para que los usuarios puedan actualizar su código.

Intente evitar eliminar la funcionalidad sin proporcionar una alternativa, esto haría que algunos de sus usuarios no estén contentos.

    
respondido por el Calmarius 13.07.2014 - 11:25

Lea otras preguntas en las etiquetas