Header Ads Widget

Ticker

6/recent/ticker-posts

Etapa de retiro del ciclo de vida de la API: una historia de las principales retiradas de API públicas

 

lifecycle_retirement2
ciclo de vida de la api

El ciclo de vida de la API es un proceso ágil de gestión de la vida de una API. Se compone de 4 fases distintas: Análisis, Desarrollo, Operaciones y Retiro.

Llega la vejez y la jubilación es parte de la vida. No es diferente en el mundo de las API. El retiro de las API de Netflix , Google Earth y ESPN son ejemplos de algunas de las grandes bajas recientes de API públicas. Cada retiro importante de API tiende a generar preocupación dentro de la comunidad de desarrolladores; ¿Están condenadas las API públicas?

No lo creemos, no olvide que actualmente hay un estimado de 13,000 API web en funcionamiento, y el sector ha mostrado un crecimiento exponencial y está programado para aumentar con el IoT ( que no es solo una moda pasajera ). Sin embargo, todo llega a su fin. A medida que cambian las condiciones, las tecnologías deben evolucionar para adaptarse a las nuevas condiciones del mercado. Una API de cara al público puede resultar exitosa para algunas organizaciones, mientras que para otras, los entornos abiertos pueden no ser viables y lucrativos.

¿Qué significa jubilación?

La jubilación puede significar muchas cosas. Es posible que se programe una versión de la API para que se desactive por completo o que la API aún exista en un formato limitado con mayores controles de acceso. Una API puede simplemente reducir su exceso de funcionalidad para volverse más consolidada y ajustada, o volverse obsoleta por una tecnología interna o un competidor externo.

Para comprender completamente las condiciones que provocan cambios importantes en la API, presentaremos 5 causas comunes que provocan la retirada de la API . Utilizando grandes depreciaciones de API de los últimos años como ejemplos, exploraremos el razonamiento detrás de cada una de las que hemos podido suponer a través de nuestra investigación. ¿Suena divertido? Creemos que es bastante fascinante lo que se puede aprender en retrospectiva ...

Banner básico-01

Razón de jubilación n. ° 1: falta de innovación de desarrolladores externos

Un escenario común que puede causar el cierre de una API es si la API está recibiendo un uso limitado o no solicitado por parte de desarrolladores y usuarios finales. Aunque esto podría deberse a un marketing inadecuado, o podría ser una prueba de que la API no ofrece un valor real a sus consumidores.

Netflix

Netflix lanzó con orgullo su programa API en 2009, citando las posibilidades de creación de nuevas aplicaciones por parte de desarrolladores externos. Finalmente, dejaron de emitir nuevas claves de API para los desarrolladores y, en 2014, se cerró para todos los usuarios, además de las integraciones de socios seleccionados. Según Daniel Jacobson, director de ingeniería de Netflix, su razonamiento fue "enfocar mejor nuestros esfuerzos y alinearlos con las necesidades de nuestra base global de miembros".

Al final, todas las solicitudes de API públicas de Netflix equivalen a aproximadamente un día de solicitudes de API privadas. La base de usuarios de la API pública era demasiado minúscula para garantizar su existencia.

El resultado fue eliminar su programa API pública para adoptar una única API Java privada / asociada. Hoy en día, todas las aplicaciones de Netflix en cualquier dispositivo se conectan a la API privada de Netflix, que realiza la recopilación, el formateo y la entrega de datos para todos los consumidores. Netflix también ha eliminado el control de versiones dentro de su API para adoptar la impermanencia y el cambio constante.

Aprendemos de este caso que cuando una marca y una plataforma nativa son tan poderosas, quizás no sea necesario crear un ecosistema con un público. Además, según el tecnólogo Andy Thurai , "se vuelve muy costoso y lleva mucho tiempo mantener" una API tanto pública como privada / de socio.

Razón de jubilación n. ° 2: oposición al incentivo financiero, la competencia

Una API pública puede retirarse si la interfaz interfiere con los objetivos comerciales principales. Al exponer sus datos para que cualquiera los consuma, los proveedores corren el riesgo de perder una ventaja de mercado, especialmente si esto les está quitando negocios a los canales de distribución nativos.

ESPN

En el caso de ESPN, su razonamiento para retirar su plataforma de datos deportivos fue "alinear mejor los recursos de ingeniería con la creciente demanda para desarrollar productos ESPN básicos en nuestra plataforma API". Hoy, si visita el Centro de desarrolladores de ESPN , notará que todas las API están abiertas para "socios estratégicos" como IFTT, Pulse y foursquare.

La discusión sobre Hacker News sugirió que se debía a que los desarrolladores estaban monetizando sus aplicaciones. Andy Thurai está de acuerdo y afirma que "la razón real parece ser que quieren un mejor control sobre su contenido exclusivo y con licencia, y una mejor monetización, que es posible que las API públicas no ofrezcan". Aprendemos que al exponer los activos internos, una empresa puede arriesgarse a perder una ventaja si al hacerlo disminuye el tráfico de los canales de distribución nativos.

Para obtener más detalles, lea el  Anuncio de jubilación .

 

Strava

Strava ofrece software de fitness para wearables con una API de desarrollador para ampliar sus aplicaciones. Comenzando con Strava API v3, comenzaron a seleccionar a sus consumidores desarrolladores con un programa de acceso limitado. Estos nuevos requisitos prohíben las "aplicaciones que fomentan la competencia", así como las que "[replican] la funcionalidad de Strava". Una gran retirada de API puede ocurrir cuando los consumidores desarrolladores incorporan técnicas de monetización en aplicaciones de terceros que rompen los términos del acuerdo original.

Para obtener más detalles, lea el  Anuncio de jubilación v1 y v2 .

 

Recorrido por la publicación del blog CTA 5-01

Razón de jubilación n. ° 3: cambios en la tecnología y consolidación de los servicios internos

La esfera tecnológica está en constante evolución. Como tal, los avances en estas tecnologías tienen el potencial de hacer obsoleta una API. Esto sucede a menudo durante rediseños internos, adquisiciones o avances de la industria externa. El retiro de API podría surgir de la evolución de las tendencias de protocolo, como REST que reemplaza a SOAP , o cambios en las experiencias del usuario final, como Netflix cambiando su modelo comercial principal de la distribución de DVD a la transmisión de video.

Skype

La razón de Skype para retirar su API de escritorio fue, según ellos, que no era compatible con las nuevas tendencias de desarrollo móvil. La API pública de Skype, introducida por primera vez en 2004 , fue asumida por Microsoft en la adquisición de 2011. La API de escritorio de Skype, propiedad de Microsoft, se cerró para incorporar las URI de Skype y el cliente de Microsoft. La terminación irritó a algunos desarrolladores, ya que borró los ingresos de las aplicaciones de terceros que consumían la API y disminuyó la funcionalidad a través de los URI de Skype .

Para obtener más detalles, lea el  Anuncio de jubilación .

 

API de datos de Google Maps

Al mismo ritmo que Google lanza nuevas API, también desaprueba las versiones anteriores. En 2010, Google anunció que suspendería la API de datos de Google Maps, un servicio creado para almacenar datos geoespaciales. La razón principal fue que se lanzó una función superior con la versión 3 de la API de Google Maps , que ofrece un método mejorado de consulta y almacenamiento que dejó obsoleta la API de datos de Google Maps .

Para obtener más detalles, lea el  Anuncio de jubilación . Algunas otras API de Google programadas para su desactivación debido a tecnología obsoleta:

Fedex

En el momento de escribir este artículo, Fedex está en proceso de actualizar sus API a Fedex Web Services, reemplazando las aplicaciones de seguimiento basadas en XML con un gran rediseño.

Para obtener más detalles, lea el  Anuncio de jubilación .

 

Razón de retiro n. ° 4: control de versiones

El control de versiones es, con mucho, la razón más común para retirar una API. Dado que las API son una tecnología relativamente nueva para la mayoría de las empresas, a menudo verá v1, v2 o v3, todavía en uso en la actualidad. Al igual que las actualizaciones del sistema operativo en los dispositivos, a menudo es más fácil desechar y reemplazar una versión completa cuando se promueve un gran cambio. El control de versiones puede surgir cuando se requieren modificaciones importantes en los parámetros de la API o nuevos controles de uso.

Algunos cambios alarmantes que afectan drásticamente a los desarrolladores y usuarios finales pueden ocultarse silenciosamente en la documentación de la nueva versión de API. Las funcionalidades pueden borrarse, los permisos limitados, las clases alteradas, etc. Dado que el control de versiones es un componente común a muchos ciclos de vida de API, no pretendemos crear una lista exhaustiva de todos ellos. Por el contrario, estos dos ejemplos de actualizaciones de versiones trajeron consigo algunas sorpresas para desarrolladores y usuarios finales ...

Youtube

YouTube, en el proceso de migración a la API de datos de YouTube v3, sorprendió a los usuarios cuando se descubrió que Data v3 ya no sería compatible con la aplicación de YouTube en televisores inteligentes costosos.

Para obtener más información, lea esta  publicación de blog de YouTube .

 

Twitter v1

La v1 de Twitter finalmente se retiró en 2013. Al ser la tercera API más popular en uso en la actualidad, el anuncio generó preocupación en toda la comunidad de desarrolladores de que la integración simplista era cosa del pasado. La actualización agregó OAuth, requiriendo claves de cliente y la creación de una aplicación con Twitter. Según Mathew Mombra , estos cambios probablemente fueron instigados a:

  • hacer cumplir la limitación de la tasa de llamadas con un acceso menos liberal
  • reducir la carga de su sistema
  • disminuir la vulnerabilidad de la API
  • promover su programa de tweets integrables

Razón de jubilación n. ° 5: preocupación por la seguridad

Una consideración de muchos retiros a gran escala, los proveedores de API pueden optar por descontinuar una API pública específicamente debido a las preocupaciones de seguridad asociadas con hacer públicos los datos y procesos internos.

API de Google Earth

La API se cerró porque se basaba en NPAPI Framework , una tecnología obsoleta que Google mencionó que se había convertido en un problema de seguridad.

SnapChat

Aunque SnapChat nunca ha lanzado técnicamente una API pública, la popular aplicación ha generado una variedad de mashups en varias plataformas que aprovechan su API "privada". Esto no se controló en gran medida, hasta principios de 2015, cuando SnapChat se asoció con la tienda de Windows para tomar medidas enérgicas contra estas aplicaciones maliciosas.

Anticiparse a la obsolescencia: ¿Qué sucede cuando cambio los parámetros de mi API?

Aunque la mayoría de los clientes se adaptan rápidamente, algunos pueden desconocer los cambios en la API. Esto significa que no responderán rápidamente para actualizar su sistema para que sea compatible con las nuevas versiones. El estancamiento, las dependencias congeladas, las bifurcaciones olvidadas y los proyectos inactivos son comunes con las API que han estado activas durante un tiempo.

Mircea F. Lungu, investigador de ciencias de la computación en Berna, Suiza, descubrió que cuando se desaprueban los métodos o clases de API, el tiempo total de adaptación dentro de un ecosistema puede variar enormemente. El período de tiempo entre la primera reacción y la última reacción puede ser de meses o incluso años.

En su estudio sobre el caso del ecosistema SmallTalk de 2.000 consumidores , Lungu descubrió que el 14% de los métodos obsoletos inducían efectos de onda negativos dentro del ecosistema, y ​​el 7% de las clases obsoletas provocaban efectos de onda. Solo el 16% de las bajas tuvieron un reemplazo sistemático, lo que significó que la mayoría de las ediciones se realizaron manualmente. Por lo tanto, cualquier cambio en una API induce ondas que pueden tener resultados de gran alcance.

Preparación para la reacción del desarrollador

Pueden surgir rápidamente ecosistemas de software completos que dependen de las API para sobrevivir. Y con la misma rapidez, pueden destruirse. Como estos desarrolladores externos han dependido de su servicio para respaldar sus propios productos, los cierres completos pueden causar inherentemente reacciones muy negativas, especialmente si no se ejecutan bien. Para mantener una buena cara con su comunidad, recomendamos la transparencia utilizando las siguientes técnicas para prepararse para el retiro de la versión de una API o su completa desaprobación.

  • Programe un plan de jubilación: ofrezca al menos un período de 6 meses para la desaprobación completa. Es de esperar que esto les dé a los equipos el tiempo suficiente para buscar nuevas integraciones o asociaciones. Considere extender este período de tiempo si ciertos equipos tienen dificultades. Google Maps y Youtube siguen un anuncio de un año de política de baja.
  • Realice cambios por etapas: nivele su plan de jubilación de una manera que se alinee con las promesas anteriores de soporte y control de versiones. Si aún se está ejecutando, apague las versiones anteriores que reciben un uso limitado al principio del proceso. Twitter ha creado útiles cronogramas de jubilación en el pasado que muestran cuándo se retirará cada versión.
  • Anuncios públicos: escriba y promueva una publicación de blog que describa explícitamente los cambios de API, cuándo entrarán en vigencia, quiénes se verán afectados y cualquier otra información vital que su comunidad necesite saber. Difunda esta información a sus cuentas sociales de desarrollador dedicadas.
  • Facilite la transición: si su API se está consolidando, versionando o fusionando en un servicio separado, facilite el proceso con una guía de migración y preguntas frecuentes . Por ejemplo, cuando los datos de Google Maps se transfirieron a Google Maps, crearon una herramienta de liberación de datos de Maps para ofrecer una descarga completa de datos o transferirlos a su nueva consola. Las transiciones incómodas pueden ser especialmente un dolor de cabeza durante las adquisiciones.
  • Utilice la prueba de apagón : la prueba de apagón es un cierre planificado de todas las funciones de la API durante un breve período de tiempo. Esto es útil para que los desarrolladores vean cómo la ausencia de la API afectará a sus sistemas y también actúa como una llamada a la acción para que los desarrolladores actualicen su código. La API de Youtube, Twitter API , API Mendely , y muchos otros han utilizado pruebas apagón en el pasado.
  • No viole sus propios términos de servicio: revise sus términos de servicio para asegurarse de que no tiene contratos vinculantes para el soporte continuo antes de desconectar. Una forma inteligente de planificar el futuro es escribir una política de obsolescencia cada vez que se crea una nueva versión de API.
  • Incluya una marca de tiempo en el campo de encabezado de respuesta HTTP Sunset  : Esto comunicará que se espera que un recurso no esté disponible en un futuro próximo. Consulte esta especificación IETF escrita por Erik Wilde para obtener más información.

Próximos pasos:

Hemos resaltado las principales preocupaciones que marcarían el comienzo de una desaprobación de API a gran escala, pero muchos retiros ocurren por una combinación de muchas de estas razones. Programar el retiro de una versión de API puede ser un gran avance hacia la reestructuración de cómo sus consumidores recibirán sus datos. En este caso, vuelva a visitar la etapa de análisis para considerar sus objetivos comerciales principales. Otras razones para considerar la depreciación o el rediseño de API a gran escala pueden incluir:

  • Competencia abrumadora con otras API en el sector de nicho
  • Incapacidad para estructurar los datos para que se reciban de forma eficaz
  • No generar ingresos para respaldar las operaciones con la oferta actual
  • y muchos otros

Elige tu aventura:

Avance a cualquiera de los siguientes artículos de la serie Ciclo de vida de API :

  1. Introducción: Visualización del ciclo de vida de la API
  2. Etapa de análisis: preparación de su estrategia de API
  3. Etapa de desarrollo: implementación de su API
  4. Etapa de operaciones:  comercialización de su API
  5. Etapa de retiro: una historia de los principales retiros de API públicas: la guía definitiva
Quiere más-01

Publicar un comentario

0 Comentarios