Header Ads Widget

Ticker

6/recent/ticker-posts

Lecciones aprendidas de la estrategia API de Apple


 

Apple es una de las plataformas API más grandes del mundo: todas las aplicaciones que se ejecutan en todos los iPhone y iPad se crean utilizando las API del gigante de Silicon Valley. Todos podemos desarrollar una mejor estrategia de API examinando cómo una de las principales plataformas de API :

  • Utiliza sus propias API dentro de su propio ecosistema;
  • Maneja cambios en estos servicios; y
  • Prioriza las experiencias del usuario final sobre otras preocupaciones.

Durante tres excelentes episodios del podcast de programación iOS / OSX, Debug , los presentadores Guy English y Rene Ritchie entrevistaron al veterano desarrollador de Apple Nitin Ganatra . Nitin ha estado en Apple durante muchos años y ha trabajado en todo, desde System 7 hasta OS X y iOS. En la tercera entrevista , Nitin y los anfitriones hablan sobre las opiniones de Apple sobre las API. Los tres no estaban discutiendo el tipo de API sobre las que solemos escribir en las API nórdicas (es decir, las basadas en la web), sino API de Objective-C de nivel inferior. A pesar de esto, la entrevista revela mucho sobre el enfoque de Apple de lo que todos podemos aprender a medida que creamos API RESTful de nivel superior.

Comida para perros sabrosa y sabrosa

En la versión inicial del sistema operativo iPhone, Apple usó clases internas para manejar operaciones como desplazamiento y tablas en sus propias aplicaciones. Estas clases tenían un buen rendimiento y eran fáciles de usar, pero solo estaban disponibles para desarrolladores de Apple. Los desarrolladores externos no tenían acceso a estas clases y, en su lugar, tenían que usar las API públicas que Apple creó para terceros. Estos eran más difíciles de usar y requerían trucos para obtener un rendimiento comparable. Para facilitar el desarrollo de aplicaciones a estas importantes partes interesadas, Apple cambió sus aplicaciones para usar las mismas clases que estos desarrolladores externos. Según Nitin, esto se hizo ".aunque sabíamos que al hacerlo estábamos ralentizando deliberadamente nuestras aplicaciones".

iStock_000015711298Pequeño

Esta "comida para perros" de la API pública obligó a Apple a mejorar la usabilidad y el rendimiento de su interfaz externa. Este tipo de prueba hace eco de las recomendaciones dadas por otros proveedores de API como Fyndiq y PlanMill que hemos compartido antes. Tenga esto en cuenta cuando desarrolle aplicaciones en su propia API. Si necesita una API especial que no está disponible para desarrolladores externos para crear su aplicación, es una clara señal de que algo podría estar mal con su API externa.

La experiencia del usuario final es lo más importante

Se habla mucho sobre la experiencia del desarrollador (DX) en los círculos de API. Esto no es sorprendente si se considera que los desarrolladores son consumidores de API. Cuando la API es el producto, es importante deleitar al cliente con grandes experiencias. Sin embargo, lo que no podemos olvidar en estas discusiones es que hay otra parte interesada muy importante: los usuarios finales de las aplicaciones. En el caso de Apple del que habló Nitin, se trata de cualquier persona con un dispositivo iOS. Si una aplicación deja de funcionar porque el desarrollador no se mantiene al día con los cambios de la API de Apple, por ejemplo, Apple la toma muy en serio, como explica Nitin:

Incluso en el caso de que un desarrollador, a sabiendas, no esté haciendo lo correcto para uno de sus propios clientes, aún así, para ese cliente, parecerá un problema de Apple. Aún puede terminar con clientes insatisfechos, y eso se reflejará mal en Apple. Tuvimos que tomarnos eso muy en serio.

Uno de los presentadores, Guy English, respondió a la explicación de Nitin sobre los puntos de vista de Apple diciendo:

Creo que lo interesante aquí es la forma en que describe al usuario final del software. Un [desarrollador] externo puede ver a la persona que usa su software como su cliente, pero Apple ve a ese cliente como un cliente de Apple. Es su deber para con sus clientes impedir que envíen API o hagan promesas a desarrolladores externos que es posible que no puedan cumplir. La intención no es limitar a los desarrolladores y las posibilidades de los desarrolladores, pero la intención es brindar a los clientes, los usuarios finales, los clientes reales, la mejor experiencia posible.

El resumen de Guy señala que el objetivo de cualquier API es proporcionar valor. Al igual que con Apple, este valor no se crea cuando un desarrollador usa la API. Más bien, se produce cuando un usuario final consume la aplicación que los desarrolladores han creado con la API. No pierda esta perspectiva mientras se esfuerza por crear la mejor API que pueda. Si lo hace, la API que cree tendrá un gran DX que a su vez ayudará a los desarrolladores a proporcionar una experiencia de usuario final fantástica.

manzana

Tenga cuidado con el cambio

Es más fácil cambiar una aplicación que cambiar una API porque la estabilidad de esta interfaz depende de muchas aplicaciones diferentes que son implementadas por diferentes desarrolladores. Como dice Guy English en el podcast:

Las API son una de las cosas más difíciles de cambiar porque siempre puedes actualizar una aplicación para solucionar un problema. [Con] una API, probablemente se quedará con ella durante mucho más tiempo del que desea.

Apple es conocida por ser conservadora con los cambios de API, y tienen buenas razones para serlo, como expresa Nitin:

Tienes que pensar en los próximos cinco años o más cuando estás implementando algunas de estas cosas o desarrollando estas API, porque, como dijo [Guy], vas a estar atascado durante años. Proviene de ese duro conocimiento de que cada vez que algo relativamente simple ha funcionado se abre camino en una interfaz, o la mayoría de las veces que ha intentado resolver un problema con una API, o proporcionar alguna funcionalidad nueva por algún "inteligente truco ”, esas son las cosas que te van a morder el culo con fuerza en tres años.

Cuando una API es popular, no puede haber cambios importantes porque tales actualizaciones afectarían a muchos desarrolladores y usuarios finales. Este tipo de pausa pone la atención en las cosas equivocadas. Como se mencionó anteriormente, UX y DX triunfan sobre el diseño de API. Se necesitarán cambios, eso es seguro. Sin embargo, cuando lo sean, tenga mucho cuidado, ya que sus repercusiones son difíciles de prever y duraderas. Después de solo un par de cambios importantes, ¿qué tan popular será su API entonces?

Resumen

De esta entrevista con Apple, podemos ver que las buenas API requieren que:

  • Centrarse en la experiencia de los usuarios finales;
  • Come nuestra propia comida para perros; y
  • Tenga cuidado con los cambios.

Este no es un consejo nuevo, pero es poderoso en su simplicidad. Escuchar estas prioridades de una empresa con tanta experiencia en API como Apple es muy convincente y digno de mención. Para obtener más información, escuche la entrevista o lea la transcripción completa usted mismo. ¡Gracias a Debug por un gran podcast y un gran agradecimiento a Nitin Ganatra por compartir!

Si ha aprendido lecciones valiosas en su proyecto de API como estas, compártalas con nosotros en Facebook , Twitter o venga a hablar en la Cumbre de la Plataforma de APIs nórdicas en octubre.

[Nota del editor: las API nórdicas son una publicación independiente y no han sido autorizadas, patrocinadas ni aprobadas por Apple Inc.]

Publicar un comentario

0 Comentarios