Header Ads Widget

Ticker

6/recent/ticker-posts

Resumen de la Cumbre de API de Austin




 

¡Una hermosa vista desde el centro de eventos Palmer en Austin!

Comprobación de micrófono. 1-2-3. A principios de esta semana, las API nórdicas celebraron un evento de 2,5 días , repleto de talleres, 30 oradores y conocimientos fundamentales sobre cómo lograr el éxito en el ecosistema de API. Esta fue nuestra primera conferencia en Austin, y nuestro segundo evento de APIs nórdicas en los Estados Unidos.

Nos divertimos mucho, aprendimos mucho y queremos compartir con ustedes algunos de los mejores conocimientos adquiridos esta semana. Vimos surgir muchos temas probados y verdaderos sobre la producción de API. También obtuvimos información sobre la rapidez del portal para desarrolladores, la generación automática de SDK, la gestión de acceso avanzada, el escalado de OpenAPI, herramientas de CI / DevOps, sin servidor, modelado de IA y más.

A continuación, describí algunas conclusiones generales y destaqué algunas sesiones de oradores que llevaron la práctica de API al siguiente nivel. Dirígete al final de los recursos específicos mencionados por los oradores.

Esperamos volver a Austin, pero mientras tanto, manténgase actualizado con las API nórdicas y considere participar en nuestra Cumbre de plataforma 2018 , que tendrá lugar del 22 al 24 de octubre en Estocolmo.

diapositivas de la cumbre de la plataforma nordic apis 2017

Oradores de SLIDES por favor envíenos!

 

CALENDARIO

presentaciones de os 2017

SESIONES - Los videos se subirán pronto

enlace de invitación secreto para unirse a la conversación de la comunidad en slack

INVITACIÓN SLACK

Tendencias generales + Conclusiones rápidas

  • Las empresas han adoptado la Productización de API : “API como producto” se llevó la palma en esta conferencia. (Alguien dijo que los oradores lo mencionaron unas 14 veces). ¿Le sorprende que en 2018 todavía estemos hablando de API como Producto? Un poco. Quizás algunos todavía no han entendido el punto.
  • El rol de API Product Manager ahora está aceptado y tiene una gran demanda : ¡No somos solo nosotros reiterando el punto del producto! Un informe reciente publicado por Gartner  dice que "Crear el rol de gerente de producto API es clave para administrar [la] dicotomía proyecto / producto". Esto parece ser parte de una tendencia, a medida que más y más gerentes de productos API ascienden para liderar iniciativas API.
  • El debate entre la generación automática de SDK y lo hecho a mano está en marcha : escuchamos a ambos lados en este caso. Los argumentos son que la reutilización conduce a una usabilidad sacrificada y SDK menos idiomáticos, pero la generación de código con herramientas como Swagger CodeGen o APImatic ahorra tiempo y recursos y mejora la automatización de CI. ¡El debate ha comenzado!
  • La seguridad es una de las principales preocupaciones en la práctica de las API : los oradores de Okta, Nevatech y Curity compartieron información sobre varios métodos para proteger y administrar las API. Es evidente que un mecanismo de seguridad API complejo es una respuesta necesaria a la histeria actual que rodea la privacidad de los datos y las violaciones públicas .
  • Relaciones con desarrolladores y desarrollo directo de casos de negocio : las API ahora son productos ( ¿lo entendiste? ), Lo que significa que el desarrollador siempre tiene la razón. Al diseñar experiencias de desarrollador, sea lo más intuitivo posible. No se trata de usted, se trata de las preferencias del consumidor, que deben ser lo primero.
  • La automatización es ahora una de las principales preocupaciones para cualquier negocio de TI ágil : desde la generación automática de SDK , la automatización de la coherencia en el diseño de API, el uso de Jenkins para actualizar los activos automatizados de cara al cliente, sin servidor y más, vimos cómo las estrategias de herramientas buscan formas de automatizar la plataforma operaciones.
  • RTFM funciona a veces, así que ¿por qué no configurarlo?:  Cree una respuesta automática para las preguntas de soporte (lea el manual "amigable"). A veces no funciona y reducir el tiempo!
  • Hemos terminado "vs." y ahora use "y" al comparar estilos de API : la competencia obstinada entre estándares puede dar lugar a muchas disputas innecesarias. Muchos ahora reconocen casos de uso separados y válidos para cosas como REST, GraphQL, gRPC y otros estilos de diseño.

Aspectos destacados de la sesión de oradores:

Lenny Markus, Paypal

Considere la divulgación progresiva para mejorar la experiencia del desarrollador

Lenny Markus describió cómo Paypal está reinventando su portal de desarrolladores para ser más progresivo

En su sesión RTFM (Read the Friendly Manual) , Lenny Markus de Paypal describió algunas ideas para mejorar las referencias API para atender a los desarrolladores de una manera utilizable.

¿Qué animal representa un desarrollador? Lenny representa a un tigre astuto pero somnoliento . Los desarrolladores son inteligentes, pero perezosos en el sentido de que tomarán el camino de menor resistencia para hacer algo.

En ese sentido, Lenny destaca una filosofía llamada  Progressive Disclosure , que es esencialmente una técnica de diseño de interacción que reduce el desorden para que sea más fácil para el usuario. Paypal está reinventando actualmente su portal de desarrolladores  para tener atributos más progresivos, y nos dieron un adelanto. Dado que ahora tienen cientos de productos centrados en el desarrollador, su nuevo portal tendrá un explorador de productos para ayudar a reducir el proceso de descubrimiento de servicios; un cambio simple, pero efectivo para mejorar enormemente la  experiencia del desarrollador .

Cecy Correa, Context.IO

¡Apoye a los ingenieros de soporte! Lucha contra los trolls y promueve horarios de trabajo saludables

Cecy Correa deja caer algunas realidades serias de la ingeniería de soporte.

En su charla  Eliminando el dolor de la ingeniería de soporte , Cecy Correa de Context.IO reconoció un hecho que se aborda con menos frecuencia sobre las API:  la ingeniería de soporte es difícil. 

¡Los desarrolladores pueden enojarse! Cuando una función no funciona, algunos se enojan y usan lenguaje grosero en desagradables correos electrónicos pasivos agresivos (vimos algunas capturas de pantalla desafortunadas).

Una gran lección para los gerentes de proyectos de API y los líderes del equipo de soporte es recordar proteger a su equipo . Como menciona Cecy: “ La cordura y la felicidad de su equipo son lo primero. ”Esto significa evitar el abuso a toda costa. La firme política contra el acoso de Cecy implica que los consumidores sepan cortésmente que Context.io no tiene ningún problema en cortar el acceso a la API si no cambian su actitud.

¡También recomienda que los equipos se  atengan al  horario comercial ! Los tickets de soporte llegan a todas horas del día. Si trabaja fuera del horario comercial solo una vez, eso podría sentar un precedente peligroso que el cliente ahora esperará de usted. Priorice una cultura de ingeniería de soporte saludable para proteger a su equipo; de lo contrario se quemarán.

Michael Hibay, Slalom

Los beneficios de UX de los hipermedia hacen que valga la pena el esfuerzo

michael-hibay

Si una API es un producto, entonces la forma en que diseñe su API es fundamental para el negocio. En su charla User Experience: Building With Hypermedia for Other Folks , Michael Hibay de Slalom defendió la inclusión de hipermedia como multiplicador de la experiencia del usuario. ¿Por qué hipermedia es una buena idea? Michael cree que da como resultado una API simple .

"Una API simple es aquella que se diseña e interactúa de la misma manera que el dominio que refleja"

Una API simple no debería traer disonancia cognitiva a un actor en ese dominio. Aunque Michael reconoce algunos riesgos potenciales (error humano, conocimiento a priori, lógica redundante), en su opinión, los beneficios de UX de hipermedia superan el esfuerzo de diseño inicial adicional.

Travis Spencer, Curity

En una inmersión profunda en OAuth y OpenID Connect , Travis Spencer profundiza en OAuth desde varias perspectivas técnicas.

Quizás OAuth realmente debería llamarse ODelegate ...

Luego de un taller de medio día sobre el tema, dentro de un grupo de charlas de seguridad API, Travis Spencer de Curity buscó conectar los puntos entre OAuth y  OpenID Connect.

Considera OAuth como una especie de meta marco "; a protocolos de protocolos. ¿Sabía que existen 50 RFC para definir cómo funcionan todos estos estándares en conjunto? La complejidad se ve agravada por el nombre inapropiado de que Auth en OAuth a menudo implica autenticación. Travis reitera que OAuth no se trata de autenticación, en realidad se trata de delegación .

Travis impartió una tonelada de información útil de OAuth sobre las capacidades de uso de tokens. Definió el tipo de tokens de OAuth, como tokens de acceso (como una sesión, que se usa para asegurar llamadas a la API) o  tokens de actualización (tokens de actualización, como una contraseña, que se usan para obtener nuevos tokens de acceso). Se refirió a las diferencias entre los flujos OAuth
(básico, implícito, híbrido, fAPI), así como los flujos de código OAuth que involucran OpenID.

Eyal Sivan, CIBC

Dicen que los bancos deben comportarse como empresas de tecnología para sobrevivir ... este se está tomando el consejo en serio

Para Eyal, no se acaba con la externalización de servicios; La arquitectura interna también debe volverse ágil.

En su charla , Eyal Sivan exploró algunas investigaciones y desarrollos progresivos y de vanguardia llevados a cabo por ... un gran banco. Espera, ¿es así? Sí, el banco canadiense CIBC está haciendo algunos cambios drásticos para sobrevivir en el verdadero cambio de paradigma que es la banca abierta .

Habiendo cocinado con el diseño de software empresarial durante décadas, Eyal todavía está tratando de eliminar las manchas de marinara del "espagueti" de los estilos de arquitectura empresarial ESB, EAI y SOA. Sin embargo, ahora cree que ha encontrado su lejía.

Al evitar los ESB y las puertas de enlace API, Eyal considera  que la malla de servicios es  un modelo más evolutivo. Él siente que "la comunicación de servicio a servicio se maneja mejor de manera distribuida". También señala que:

"Si su objetivo es la velocidad, los microservicios son su salsa secreta, no las API"

Una gran cantidad  está cambiando debido a la presión de regulación ( PSD2 ) y las nuevas expectativas del mercado. Los bancos pronto podrían ser " uberizados ". Reemplaza que se acerca el invierno con  Silicon Valley y comprenderás el miedo. El uso de un marco de microservicios basado en tecnología de código abierto es el método de CIBC para mantenerse relevante a través de la turbulencia.

James Higginbotham, LaunchAny

¿Qué estilo de diseño de API debo utilizar?

James Higginbotham compara estilos de API

A través de su trabajo de consultoría de API a través de LaunchAny, James Higginbotham está muy familiarizado con esta pregunta. En su sesión,  ¿las API REST siguen siendo relevantes hoy en día? , examina los estilos de API populares de 2018 ( GraphQL , gRPC , REST y webhooks ) para tratar de encontrar la respuesta.

Dado que las API se pueden utilizar para resolver una variedad de casos de uso, James recomienda que considere qué estilo de interacción tendrá su API antes de adoptar una u otra: ¿es una solicitud / respuesta, como la mayoría de los puntos finales, o una solicitud / reconocimiento, o ¿Realmente necesitas GETdatos por lotes? Luego compara estilos como tales:

  • GraphQL : funciona bien con gráficos de objetos. Soporte de datos jerárquicos. Buen ajuste para las API de front-end. Aplicación de seguridad limitada. Falta de capacidad de almacenamiento en caché. Limitado a tipos de contenido específicos.
  • GRPC : Se parece a CORBA. alto potencial de rendimiento: consulte el SDK de Google Cloud como prueba. HTTP 2 / bidireccional. Baja latencia. Utiliza protobufs para la generación de código. Depende de los generadores de código para hacer lo correcto. Falta de cahceabilidad. Mejor para backend.
  • REST:  HTTP + JSON es confiable. Las URL definen rutas de recursos, los verbos permiten la interacción con el servidor. Los encabezados toman detalles, tenemos códigos de respuesta, negociación de contenido, almacenamiento en caché y control de concurrencia. Hypermedia puede ofrecer personalización para dispositivos o interfaces únicos. Lea su inmersión profunda en los  conceptos de HTTP aquí .
  • Webhooks : gran potencial. Por ejemplo, Github usa webhooks para todas las solicitudes de extracción, han "creado un mercado completo que no existía antes" que no existiría sin webhooks.

En definitiva,  , REST sigue siendo muy relevante . Sin embargo, averigüe qué estilos se adaptarán a la mayoría de los desarrolladores y canales que está creando y compile en consecuencia.

Kelly Grizzle, Sailpoint

Domina el mundo con una API para aprovisionar datos de usuarios.

A menudo discutimos las diferencias entre las API públicas , las API de socios y las API que se utilizan estrictamente para fines internos y privados . Nos gustaría presentar una cuarta generación: la API estándar de Internet . Como cubrimos en el blog en el pasado , SCIM , Sistema para administración de identidades entre dominios, es un nuevo estándar para la administración de identidades. El objetivo es hacer que sea rápido, económico y fácil mover usuarios dentro y alrededor de la nube mediante la automatización del aprovisionamiento de usuarios con una API REST. En su charla,  Kelly Grizzle de Sailpoint anuncia su objetivo de "dominar el mundo" - con 2.0 lanzado en 2015 como  ETF RFC 7643, SCIM ahora es adoptado por cientos de organizaciones en todo el mundo y la adopción crece.

John Bindel, asistente de las API nórdicas por primera vez, profundiza en las preguntas y respuestas

Palabras de sabiduría API

  • "Las API no se tratan de integración, se trata de un consumo sin fricciones"  Lou Powell , Vanick Digital
  • Kristof Van Tomme de Provonix describió cómo realmente necesitamos centrarnos más en las API internas , y estoy de acuerdo. Quizás puedan tomar una página de la comunidad de innersourcing.
  • "Cuando optimizas para la reutilización, normalmente sacrificas la usabilidad" -  Irakli Nadareishvili
  • ¿Alguien recuerda haber jugado el juego de computadora retro Lemonade Stand ? Chris Busse de APIVista cree que los proveedores de API también podrían usar una dosis similar de economía básica.
  • “Siga siempre un enfoque de arriba hacia abajo: comience con las necesidades del negocio y del consumidor, luego utilícelo para diseñar API” - Keshav Vasudevan , SmartBear

Recursos de las sesiones de oradores

Para una mayor exploración, aquí hay enlaces a marcos, estudios y otros recursos enfatizados por los oradores:

  • Elementos nube Estado de la Unión :  Salida nube Elementos encuesta anual, tal como fue revisado por Ross Garrett  en su presentación.
  • Marco del pacto : este marco para el diseño basado en contratos fue revisado por Henrik Stene de Knowit. Voló desde Noruega. ¡Felicidades por tu primera charla en la conferencia, Henrik!
  • El poder de HTTP : James Higginbotham mencionó su amplia descripción general de los conceptos de HTTP. Lea para asegurarse de aprovechar HTTP al máximo.
  • Generador de OpenAPI : Tristan Sokol de Square identificó cómo generan SDK automáticamente usando Swagger Code Gen y TravisCI .
  • Generador de biblioteca de cliente de API de Kaltura : Avital Tzubeli  de Kaltura describió este generador de cliente interno que hicieron para crear SDK idiomáticos. Github Repo .
  • Especificación de OpenAPI : conozca la especificación, las herramientas disponibles y la comunidad que las rodea.

¿Tiene más información?

¿Disfrutaste de alguna sesión específica o tienes preguntas para los ponentes? Nos encantaría leer sus comentarios en un  comentario a continuación . En ese sentido, si desea dar una sesión en el futuro, aquí está nuestro Call For Papers .

Encuesta: Ayúdanos a mejorar

Amablemente pedimos a todos los asistentes que completen nuestra  encuesta de 10 preguntas . ¡Ayudará enormemente a nuestros esfuerzos para mejorar nuestros eventos y regresar a Austin!

¡Gracias ya!

Gracias a nuestro organizador  Curity , ya nuestros patrocinadores  SmartBear , la luz de parada , y Nevatech ! ¡No podríamos organizar estos eventos sin su apoyo! ¿Está interesado en patrocinar un próximo evento? Dirígete a esta página para obtener más detalles.


Siguiente: Platform Summit 2018

plataforma_cumbre-2018

Planeamos regresar a los EE. UU. En el futuro, pero entre entonces y ahora es la Cumbre de la Plataforma 2018 en Estocolmo, Suecia, del 22 al 24 de octubre. Este será nuestro evento más grande hasta el momento, una conferencia de API verdaderamente  global que incluirá oradores de primer nivel que representan a los principales actores de la industria. Asistentes: ¡ obtenga su boleto hoy  y estad atentos a los anuncios suscribiéndose a nuestro boletín !

Publicar un comentario

0 Comentarios