Header Ads Widget

Ticker

6/recent/ticker-posts

Opinión sobre APIStrat en Portland

 Resumen de la conferencia de estrategia y práctica de API celebrada en Portland del 31 de octubre al 2 de noviembre. 

La semana pasada tuve la suerte de asistir, hablar y conocer nuevos entusiastas de API en  APIStrat en Portland, Oregon. API Strategy & Practice es una serie de conferencias de calidad con temas de API que se celebran en todo Estados Unidos, originalmente organizadas por API Evangelist y ahora adoptadas como un evento de la Fundación Linux .

El evento de 3 días fue una colección de consejos de expertos de la industria de API sobre el diseño de API y las mejores prácticas para su usabilidad. Lo más destacado fue escuchar lo que los miembros del Comité de Desarrolladores Técnicos (TDC) tenían que decir sobre la historia y la evolución futura de la  Especificación de API abierta  (OAS), el formato de definición de API posterior a Swagger ahora de código abierto.

Resumir una conferencia de esta magnitud es difícil, ya que solo pude ver una parte de las tres  pistas  y más de 70  sesiones. Entonces, en este artículo resumiré el panel de discusión de OpenAPI , destacaré cuatro charlas que resonaron conmigo y señalaré algunos temas recurrentes en torno al diseño de API. En general, el  futuro es brillante , la empatía es clave y la Iniciativa de API abierta (OAI) tiene la luz de las antorchas.

Pero lo más importante, ¿deberíamos cambiar el nombre del formato de descripción de API pináculo al de una adorable  jirafa cebra nativa del Congo? Más sobre esa pregunta fundamental a continuación.

Las guerras de formatos de datos han terminado

La especificación OpenAPI recibió un enfoque importante en esta conferencia. El panel de discusión con el creador de Swagger, Tony Tam, la embajadora de OAI Erin McKean, y los miembros de TDC, Ron Ratovsky y Darrell Miller, arrojaron luz sobre la evolución  de la industria  y las áreas de crecimiento  para v3 y más allá.

Hemos recorrido un largo camino desde los días de las  guerras de formatos de datos , donde las comparaciones de formatos como XML, JSON y YAML coincidían con el acalorado debate sobre WSDL, SOAP y REST . Sin mencionar la rivalidad entre los formatos de descripción API Blueprint, RAML y Swagger.

“Perdimos varios años peleando por lo mismo” 
-Tony Tam, creador de Swagger (ahora OAS)

Afortunadamente, las cosas se sienten más estables ahora que la industria se ha fusionado en gran medida en torno a la API HTTP cubierta con el estándar OAS ( ahora en la versión 3 ). La OEA se ha convertido en un mecanismo de integración de facto, así como en una ventaja competitiva. En pocas palabras, Miller, "obtendrá más clientes proporcionándolo".

¿Hacia dónde se dirige la OEA?

OAS parece ser compatible para describir la mayoría de los servicios web. Sin embargo, existe una preocupación creciente sobre cómo extender la especificación en el futuro, específicamente sobre cómo agregar formas de describir la mensajería basada en eventos .

Si bien OAI sigue las capacidades de las API basadas en HTTP y, por lo tanto, la Especificación HTTP, no debería describir cosas que no encajen en ese ámbito. Sin embargo, parece que siempre habrá un debate sobre cómo equilibrar mejor la  simplicidad y la complejidad . 

Por lo tanto, a medida que se expanda el uso de la OEA, ¿cómo evolucionará? El TDC ha estado ocupado recibiendo comentarios y reiterando para mejorar la especificación, pero ve espacio para evolucionar en ciertas áreas como:

  • Mensajería basada en eventos : los usuarios han solicitado la capacidad de describir diferentes tipos de protocolos de mensajería basados ​​en eventos.
  • Soporte para otros tipos de contenido : la OAS está muy absorta en el esquema JSON, pero técnicamente la especificación de la API es independiente del formato. Podría hacer un mejor trabajo para atender Protobuffs , consultas GraphQL y otros tipos de contenido.

La OAI ha establecido una base sólida. Pero para permitir que el desarrollador promedio aproveche todo su potencial, realmente necesitamos una  comunidad de implementaciones de herramientas de terceros . Los generadores de código, los generadores de documentación, los visualizadores y las bibliotecas de nicho impulsarán el uso a nuevos dominios.

"OkAPI" tiene nuestro voto

Will, un ternero Okapi nacido recientemente en el zoológico de Brookfield en Chicago, Illinois. ¡Espero verlo en APIStrat 2018!

Solo mira este tierno okapi bebé con rayas de cebra. Los okapis, de la familia Giraffidae, son nativos de una región muy pequeña del Congo en África central. Bien podrían ser la mascota que quiere nuestra industria. Nuestra industria necesita .

Criado en APIStrat: ¿Debería cambiarse el nombre de OEA a OkAPI?

Convenientemente nombrada con el acrónimo API en su lugar (supongo que los congoleños fueron los primeros RESTafarianos), una mascota Okapi podría ser un lindo compañero visual para una especificación que actualmente carece de tema y personalidad.

Si bien cambiar el nombre de " Especificación de API abierta " a " OkAPI " parece gracioso al principio, aquí hay una estrategia. Las ayudas visuales pueden unir la tecnología para hacerla más memorable y, por lo tanto, adoptada más ampliamente. Esto recuerda a la RAM en RAML.

Además, OpenAPI Specification es un bocado, mientras que  OkAPI fluye de la lengua fácilmente. Solo tendremos que decidir cuál es la pronunciación exacta: ¿  oh-kah-pee  o  oh-kay-API?

Okapi se deriva de la palabra pigmea O'Api que, cuando la pronuncian los pigmeos, suena como okapi. Zoológico de San Diego

Por supuesto, un rediseño de marca tan masivo es descabellado, y quizás esto fue solo una broma. Cualquier cambio será, en última instancia, decisión de la OAI. Pero para que conste, Okapi, o OkAPI, tiene mi respaldo.

El futuro es brillante

Sátira ampliamente compartida sobre los silos heredados de Microsoft

El primer día vio algunas ponencias impresionantes. La inauguración de la conferencia fue Yina Arenas , directora principal de programas de Microsoft. Primero compartió una popular pieza de sátira sobre las estructuras organizativas de las empresas. Lamentablemente, hasta hace poco, Microsoft no tenía la mejor reputación de colaboración entre departamentos.

Sin patrones ni consistencia, los productos de Microsoft estaban super aislados. La colaboración fue un gran lío. Afortunadamente, una iniciativa de API primero nació de abajo hacia arriba.

Al aceptar estandarizar con REST, ID de Canonical y gobernanza de API, sus equipos rompieron con éxito los silos y tradujeron la pasión del cliente en valor para el cliente. Esto culminó en Microsoft Graph y las siguientes pautas de API . ¡No más armas!

Ten empatía. | Ganancias | - | Pérdidas | > 0

Una palabra común que seguimos escuchando en esta conferencia fue " empatía ". Es inspirador ver que los límites disminuyen a medida que el espacio de la API se fusiona en un terreno común. Como probablemente te dijo tu mamá, trabajar juntos es mejor para todos. resulta que tener empatía en los negocios, en realidad, podría estar científicamente probado para aumentar el éxito de todos los involucrados.

En la charla de Sarah Novotny sobre API abiertas y el poder de los juegos de suma positiva , habló sobre cómo se están erosionando los límites, y mucho de eso se basa en la empatía.

“Ahora estamos en un punto de inflexión en nuestra industria. El futuro es brillante ”
-Sarah Novotny

Dado que los programas de API dan importancia al diseño , la usabilidad, la participación de la comunidad y la experiencia del desarrollador , la empatía se ha convertido en un valor comercial definitivo. Como las API comparten información, la empatía es la base de estas transacciones. Novotny equipara esto a  la teoría de juegos de suma positiva ; esencialmente, si trabajamos juntos, las ganancias positivas superan las pérdidas.

Las API abiertas y las tecnologías componibles están beneficiando a todo el ecosistema. Darrell Miller, un acérrimo defensor de los hipermedios que irónicamente luchó contra Swagger en sus inicios, es ahora un miembro central de OAI TDC. Nos recuerda que no debemos  " ignorar las cosas exitosas por razones teóricas". Combinar los mejores enfoques y hacer que trabajen juntos es mucho mejor que vivir en una oposición obstinada.

Reutilizar! = Eficiencia

En el mundo del software, a menudo se aclama la reutilización del código para mejorar la eficiencia y disminuir el esfuerzo de desarrollo. Aunque la reutilización de código se suele considerar positiva, es posible que no sea la solución de oro.

En su charla La maldita falacia de asumir que la reutilización es el camino hacia la eficiencia: aprovechar los microservicios para la experimentación  ( diapositivas ), Irakli Nadareishvili de Capital One trató de dejar las cosas claras. 

El  principio de la irregularidad sostiene que ninguna persona es completamente "normal"; todos tenemos una multitud de características individuales. Por lo tanto, reutilizar los requisitos promedio en todos los ámbitos puede resultar en una mala usabilidad. Tomemos una historia de la construcción de aviones en la década de 1940:

“Las cabinas se diseñaron originalmente en torno al rango medio de 10 medidas corporales tomadas de una población de 4.063 pilotos. Pero debido a que ningún piloto cumplía con todos esos criterios, terminaron con un asiento que en realidad no se ajustaba a nadie ". Qi.com

Dado que las proporciones humanas son variables, los asientos resultaron inútiles para casi todos los pilotos que los probaron y tuvieron que ser destruidos. ¿La moraleja de la historia de los microservicios ? Sea selectivo en su reutilización:

"Trate de evitar diseñar para casos de uso promedio para maximizar el uso"

El hecho de que existan promedios medios no significa que deban seguirse religiosamente. Estandarice protocolos y contratos, y comparta vocabularios comunes. Mientras que se recomienda la reutilización de servicios ampliamente adoptados, Nadareishvili considera que las bibliotecas personalizadas y ciertos modelos de datos no deben reutilizarse.

7 tendencias importantes de diseño de API

¿Cómo está evolucionando el diseño de API con la llegada de nuevas tendencias como bots , IoT y aplicaciones impulsadas por eventos ? ¿Estamos mapeando correctamente las transacciones cliente-servidor modernas en el diseño de nuestras API?

En pocas palabras, el diseño de API está cambiando. En su charla  Diseño de API en la era de los bots, IoT y voz ( diapositivas ),  James Higginbotham describió 7 áreas que están alterando la forma en que diseñamos las API:

  1. Hipermedia y HATEOAS
  2. Suscripciones a eventos
  3. Diseño de API impulsado por la capacidad
  4. Negociación de contenido
  5. API de contexto de front-end
  6. API en el dispositivo
  7. Bots como API de próxima generación

La mayoría de las API web todavía están atascadas en la tierra de CRUD (Crear, Leer, Actualizar, Eliminar), que no refleja el procesamiento del lenguaje natural en absoluto. Higginbotham nos recuerda que el diseño de API no es su base de datos, sino que en realidad es una preocupación arquitectónica que combina negocios, diseño de productos y  tecnología externa.

 

Incluir un diseño de estilo de elegir tu propia aventura con hipermedia  podría hacer que las aplicaciones sean más flexibles, y se pueden lograr interacciones basadas en el contexto mediante la negociación de contenido . En general, las nuevas tendencias, como los comandos de Alexa o las API en el dispositivo, implican nuevas relaciones cliente-servidor que podrían atraer un enfoque de capacidad para diseñar nuevas capas de interacción API.

Gran enfoque en la usabilidad de API en APIStrat

Los paneles de discusión y las 4 sesiones anteriores fueron solo la punta del iceberg del conocimiento presentado en APIStrat. Se habló mucho sobre gRPC , JSON Schema , creación de guías de estilo API, mejora de la documentación y otras prácticas para la experiencia de desarrollador A +.

Para redondear las cosas, más conocimientos sobre el modelado de negocios de API y la monetización podrían haber empoderado a algunos asistentes nuevos, pero estoy seguro de que otros eventos de APIStrat destacarán esos temas en el futuro.

Saludos a los organizadores y patrocinadores que lo hicieron posible, ya los ponentes por ofrecer charlas tan atractivas. Este fue también el primer año en que APIStrat fue organizado por la Fundación Linux, e hicieron un gran trabajo con estructura y programación clara. Felicitaciones a todos los que participaron. ¡La comunidad #APIStrat es genial !

Recursos:

  • Calendario completo de APIStrat 2017 Portland
  • Iniciativa API abierta
  • Sesiones destacadas (en orden de aparición):
    • De armas a gráficos . Yina Arenas.
    • API abiertas y el poder de los juegos de suma positiva. Sarah Novotny.
    • La condenada falacia de asumir que la reutilización es el camino hacia la eficiencia: aprovechar los microservicios para la experimentación . Irakli Nadareishvili. Diapositivas .
    • Diseño de API en la era de los bots, IoT y Voice. James Higginbotham. Diapositivas .

Publicar un comentario

0 Comentarios