Gestión de productos API | Kamal Kannan | Skillshare
Menú
Buscar

Velocidad de reproducción


  • 0.5x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 2x

Gestión de productos API

teacher avatar Kamal Kannan, Product Manager

Ve esta clase y miles más

Obtenga acceso ilimitado a todas las clases
Clases enseñadas por líderes de la industria y profesionales activos
Los temas incluyen ilustración, diseño, fotografía y más

Ve esta clase y miles más

Obtenga acceso ilimitado a todas las clases
Clases enseñadas por líderes de la industria y profesionales activos
Los temas incluyen ilustración, diseño, fotografía y más

Lecciones en esta clase

    • 1.

      Introducción

      1:56

    • 2.

      El caso para productos API

      2:22

    • 3.

      Ejemplos de productos API

      5:58

    • 4.

      Qué y por qué un gerente de productos debe saber sobre las API

      1:20

    • 5.

      Qué es una API

      0:55

    • 6.

      Cómo funcionan las API

      1:21

    • 7.

      ¿Qué son los servicios web

      1:01

    • 8.

      Qué es una API de REST

      0:47

    • 9.

      Elementos de una API

      0:16

    • 10.

      Métodos HTTP

      1:12

    • 11.

      Solicitud y respuesta de API

      1:27

    • 12.

      Datos (carga útil)

      1:29

    • 13.

      Encabezado de API

      1:26

    • 14.

      Lección de bonificación - Webhooks

      2:40

    • 15.

      La mentalidad de productos de API

      3:20

    • 16.

      Ciclo de vida de API

      1:28

    • 17.

      Cómo crear un producto viable

      1:40

    • 18.

      Diseño, desarrollo y lanzamiento de productos de API

      2:44

    • 19.

      Cómo impulsar la adopción a través de una experiencia intuitiva

      2:03

    • 20.

      Métricas que importan

      2:13

    • 21.

      Versionado de API

      3:23

    • 22.

      Héroes de una API mal diseñado

      1:22

    • 23.

      El valor de una API bien pensada

      0:59

    • 24.

      Quién formar el equipo de API

      0:46

    • 25.

      Introducción a estrategias de fijación de precios

      1:06

    • 26.

      Opciones de precios

      0:25

    • 27.

      Actores de economía de API

      1:21

    • 28.

      Precios de API

      1:05

    • 29.

      Pagos para desarrolladores de precios

      2:14

    • 30.

      Desarrollador de precios de API

      1:12

  • --
  • Nivel principiante
  • Nivel intermedio
  • Nivel avanzado
  • Todos los niveles

Generado por la comunidad

El nivel se determina según la opinión de la mayoría de los estudiantes que han dejado reseñas en esta clase. La recomendación del profesor o de la profesora se muestra hasta que se recopilen al menos 5 reseñas de estudiantes.

136

Estudiantes

1

Proyectos

Acerca de esta clase

Hace casi una década que soy un producto administrativo. Más recientemente, he estado gestionando productos API para la industria de tránsito.

Como gerentes de productos, a menudo no es fácil de entender la tecnología y para aquellos que empiezan puede ser un poco abrumador. Si no es algo que deberías estar realmente cómodo con el mundo de las API. Porque puedes consumir una API para tu producto o exponerte tu API para consumo de terceros.

A través de esta clase tengo la intención de deconstruct el mundo de las API para administradores de productos. Aprenderás los conceptos básicos de las API, la tecnología detrás de ésta, la gestión de productos para productos API y estrategias de precios.

Incluso si eres completamente nuevo en los conceptos de gestión de productos, ¡encontrarás que estos conceptos y técnicas simples y efectivos son fáciles de entender y aplicar en tu camino hacia una carrera en gestión de productos de API!

Conoce a tu profesor(a)

Teacher Profile Image

Kamal Kannan

Product Manager

Profesor(a)

Hey there! I'm am an experienced Product Manager who has managed products for companies based out of India, the USA and the UK. 

Early on in my career, I got exposed to the concepts of Design Thinking as a part of Intellect Design Arena, who are pioneers in Design Thinking in India. Since then, I have successfully applied design thinking concepts in solving complex problems and coming up with innovative product solutions.

Ver perfil completo

Level: Intermediate

Valoración de la clase

¿Se cumplieron las expectativas?
    ¡Superadas!
  • 0%
  • 0%
  • Un poco
  • 0%
  • No realmente
  • 0%

¿Por qué unirse a Skillshare?

Mira las galardonadas Skillshare Originals

Cada clase tiene lecciones cortas y proyectos prácticos

Tu membresía apoya a los profesores de Skillshare

Aprende desde cualquier lugar

Ve clases sobre la marcha con la aplicación de Skillshare. Progresa en línea o descarga las clases para verlas en el avión, el metro o donde sea que aprendas mejor.

Transcripciones

1. Introducción: Hola a todos, ya voy. Soy gerente de producto con sede en el Reino Unido. De todos los productos que se manejan en mi carrera. El más desafiante de ellos han sido los productos API. Y cada vez más empresas están empezando a ver las API como productos. Por ejemplo, si visita una empresa en el mundo, sea PayPal stripe, Facebook, Twitter, o cualquier empresa. Encontrarías reglas para productos API o gestores productos con experiencia en desarrolladores. Pero, ¿cómo te preparas para estos roles? Lo que fue un reto para mí cuando estaba empezando fue la falta de un recurso centralizado que hablara API específicamente para los gerentes de productos. Ahora este curso, mi intento simplificar las API y hacerlo más comprensible para cualquiera que comience nuevo en el mundo de las API y la gestión de productos. Entonces, ¿cómo, cómo estructuré este curso? Empezaremos primero entendiendo algunos ejemplos de productos API. Después entraremos en los fundamentos de las API. ¿ Cómo funcionan realmente las API? ¿ Cuál es la tecnología detrás de las API? También veremos un ejemplo de uso de una API y a través de Postman. Y luego entraremos en el manejo de productos de una API. Cómo entrar en la mentalidad del producto API. ¿ Cuál es el ciclo de vida de una API? Cómo seguir adelante y construir, medir y hacer crecer los productos API. Y luego nos adentraremos en los roles y responsabilidades del equipo de API así como del gerente de producto API. Y por último, veremos el modelo de negocio. ¿ Cómo se deben fijar los precios de las API? ¿ Cuáles son las diferentes opciones de precios disponibles para nosotros? lo que ojalá al final de este curso, tengas una comprensión bastante buena de lo que son las API, por qué deben ser vistos como productos, y cómo manejarlos como productos. Gracias por escuchar y esperar verte del otro lado. 2. El caso para productos de API: Hola a todos. Por ahora esperemos que tengas una comprensión justa de lo que es una API y lo que hace la tecnología de TI detrás de ella, y cuáles son los diferentes tipos de API y así sucesivamente. Veamos ahora el caso de un producto API. ¿ Por qué debería empezar a mirar las API como un producto desde el principio ya que la industria del software estaba evolucionando tradicionalmente las aplicaciones y construía unas aplicaciones de regla estándar. Podría tener un sistema de recursos humanos. Podría tener un sistema de gestión de nómina. Podría tener un sistema de gestión de ventas. Podría tener un sistema de gestión de marketing y así sucesivamente. Por lo que cada uno de estos sistemas donde esencialmente aplicaciones en silos, pero eventualmente había una necesidad de que estas aplicaciones hablaran entre sí, y por lo tanto, se estaban desarrollando interfaces. Y entonces los equipos se dieron cuenta de que en lugar de construir las aplicaciones primero y luego pensar en interfaces más adelante, deberían comenzar con un primer enfoque API, trataremos de construir microservicios que puedan ser consumidos por otras aplicaciones y así sucesivamente. Por lo tanto, tenías API privadas donde los diferentes equipos dentro de la empresa consumen estas API para que los sistemas puedan solicitar información de otras aplicaciones fácilmente. Ahora, eventualmente, las empresas más inteligentes se dieron cuenta de que las API son mucho más que las suyas. Y las API se pueden ver como productos ellos mismos. Por ejemplo, puedes usar tu Google Maps como aplicación independiente en tu navegador o en tu teléfono móvil. No obstante, Google también tiene una API, Maps API, que está disponible para que los desarrolladores públicos puedan usar este mapa a API y luego crear productos innovadores a su alrededor. Por ejemplo, tus aplicaciones de uso compartido como el Uber y Ola han utilizado la API de Google Maps para proporcionar experiencias intuitivas a los clientes. Otro buen ejemplo es PayPal. Puedes usar PayPal para enviar dinero, recibir pagos y así sucesivamente. Pero la gente también tiene API que los negocios pueden usar para integrar los pagos de PayPal en su sitio web a través cual los usuarios pueden comenzar a comprar el lado izquierdo. Y PayPal hace mucho dinero a través de estas API mismas. Se dice que empresas como Expedia hacen al menos el 90 por ciento de los ingresos solo de API. Ebay se puso a hacer alrededor del 60 por ciento de sus ingresos a partir de API. Por lo que las API necesitan ser vistos como productos en sí mismos donde entienda la necesidad específica del cliente y construya API que puedan servir a ese viaje del cliente. Entonces ahí es donde las API necesitan ser miradas como productos. Y la gestión de productos APA entra en panorama. Gracias por escuchar y esperar verte en la siguiente clase. 3. Ejemplos de productos de API: Hola a todos y bienvenidos a esta clase y tire, quiero darles un resumen rápido de lo que es un producto API. No voy a hacer eso mostrándote algunos ejemplos de producto API popular. Y obviamente vamos a hablar de la tecnología detrás de la API. ¿ Qué es una API y cómo funciona? Y qué es la gestión de productos API y así sucesivamente en las próximas clases. Pero antes de entrar realmente en los detalles de eso, creo que es importante que todos tengamos una comprensión compartida de lo que es un producto API. Entonces, veamos PayPal por ejemplo. Entonces, ¿qué es PayPal? Paypal es un producto que nos ayuda a realizar pagos o recibir pagos de alguien. Por lo que tienen un hermoso producto basado en UI que muchos de ustedes podrían haber usado. También cuentan con API. Por lo que proporcionan, para que ella mirara su página web. Hay una sección llamada desarrollador, y si haces clic en eso, que proporciona todas las API que los desarrolladores de terceros pueden usar para integrar en pagado, pagado. Entonces si haces click, por lo que tiene documentación para las diferentes API. Y si haces clic en API, puedes ver cuáles son las diferentes API en el cómo, ¿ cómo realmente inicias sesión en el panel? ¿ Cómo se obtienen las credenciales para acceder al token? ¿ Cómo se realizan las llamadas API? Tienen un sandbox, esencialmente es un entorno de prueba donde se puede probar la API y tienen algunos ejemplos. Por lo que todo esto está destinado a ayudar a los desarrolladores de terceros a comprender más sobre las API, las capacidades de las API, y luego comenzar a consumir las API. Entonces ese es un ejemplo. El otro gran ejemplo es Twilio. Twilio es muy conocido por sus productos basados en API. Nuevamente, cualquier aplicación popular producto Pablo que veas en estos días tendría una sección específicamente destinada a desarrolladores. Y Twilio también tiene una sección para Delta Force y cuenta con algunas de sus populares API. Por ejemplo, cuenta con una API de WhatsApp. Demos click y veamos qué tiene en realidad. Entonces de nuevo, es una documentación. Ha contado prolijamente ¿cómo se empieza como desarrollador? ¿ Cómo puedes empezar con esta API? ¿ Cuáles son la referencia, cuáles son las guías y tutoriales para que empieces a usar esta API? Y esencialmente nos ayuda a empezar a consumir la API fácilmente. De igual forma, cuentan con múltiples productos a los que todos han sido expuestos como API. También cuentan con kits de desarrollo de software. Nuevamente, estas son bibliotecas que como desarrollador podrías usar fácilmente y comenzar a construir las aplicaciones. Y sólo ellos tienen kits de desarrollo separados para Android, iOS, y así sucesivamente. Entonces sigamos y veamos la API de Google. Entonces como sabrías, Google Maps, por ejemplo, es un producto que cualquiera puede usar de forma gratuita. Por lo que instalas la app en tu teléfono o puedes abrir la aplicación Google Maps en tu navegador y luego empezar a usar la aplicación Maps. No obstante, Google también proporciona una API para que los desarrolladores de terceros comiencen a usarlos. Por ejemplo, las aplicaciones para compartir rutas como Ola, Uber usan la API de Google Maps para proporcionar la integración de Maps como parte de su propia aplicación. Por lo que cualquiera puede empezar a usar este KPI. Por lo que tienen un sitio web llamado desarrolladores dot google.com. Entonces eso está destinado específicamente para los desarrolladores. Queremos utilizar los productos de Google caso de uso específico. Y ahora echemos un vistazo a la documentación aquí. Y de nuevo, esto también nos dice lo fácil que puedes empezar con el uso de la API. ¿ Cómo configura su proyecto? ¿ Cómo se habilita la API o el SDK? ¿ Cómo se obtiene la clave API, y así sucesivamente y así sucesivamente. Y luego también cuentan cómo, cómo elegir una API. Entonces si querías agregar un mapa a una aplicación de Android, entonces usas el SDK de Maps para Android. De igual manera, tienen diferentes casos de uso y las API específicas que realmente puedes usar para estos diferentes casos de uso. Echemos un vistazo también a una API específica y d, d, digamos que tienes la API de Roads. Echemos un vistazo a la API más cercana. Entonces este es un endpoint API y las carreteras más cercanas esta API, este es el endpoint al que golpearás. Estos son los parámetros de consulta que usarás para filtrar realmente tus resultados en función de lo que necesites. Y esta es la clave API que enviarás. Entonces esta es la API específica que usarás. Y esta documentación nos dice cuáles son diferentes ejemplos. Si quisieras usar esto a través de Java, Python, Ruby, Go y carteros y así sucesivamente, también puedes ejecutar esto en carteros, que es una aplicación muy popular para probar tus API. Ya veremos cómo hacerlo en las clases posteriores. Entonces así es como se ve la respuesta y así sucesivamente. Entonces, esencialmente lo que hemos visto a través estos tres productos diferentes es que a pesar de que cada una de estas empresas tiene productos muy exitosos en sí mismas, también tienen mucho cuidado en exponer las API a desarrolladores de terceros. Por lo tanto, muchas veces estas empresas tendrían gestores de productos dedicados que gestionan estas experiencias en torno a estas API. Porque los desarrolladores que van a estar usando esta API son los verdaderos usuarios de este producto. Los gerentes de producto necesitan realmente entender ¿qué es lo que quieren los desarrolladores? ¿ Cuáles son sus puntos de dolor? ¿ Cuáles son los casos de uso específicos para los que podrían utilizar una API? Construido no, y no solo construir API, sino también construir la experiencia y el objeto del desarrollador. Esencialmente llegar a la documentación, llegar a ejemplos, llegar a entornos sandbox, esencialmente llegar a todos los detalles de soporte para ayudar a los desarrolladores a ponerse en marcha rápidamente. Entonces eso es lo que es el producto API. Esencialmente es que no es solo la API, sino también la experiencia del desarrollador a su alrededor. Esperemos que eso te haya dado una comprensión bastante buena de lo que son los productos api. No te preocupes si aún no tienes plena confianza. No te preocupes si aún sientes un poco a medida que avanzamos por el curso. Por lo que tendrías una comprensión mucho mejor de las API y la administración de productos API. Gracias por escuchar y esperar verte en la siguiente clase. 4. Qué y por qué un gerente de productos debe saber sobre las APIs: Como gerente de producto, vas a estar invariablemente involucrado en el uso de API de una madre real. A continuación se presentan los tres escenarios diferentes en los que podrías estar involucrado en el uso de las API. En primer lugar, podría estar tratando con API internas que diferentes equipos dentro de su organización usan para casos de uso compartido. En segundo lugar, podría estar consumiendo una API de terceros como parte de su experiencia en el producto. Por ejemplo, si eres un gestor de productos de Uber, podrías estar usando la API de Google Maps para tus propios casos de uso. En tercer lugar, alternativamente, si eres un gestor de productos de Google, podrías estar exponiendo una API de Maps para que pueda ser consumida por desarrolladores de terceros como Uber con el fin de usar casos de uso propios. Por lo que es importante que los gestores de productos entiendan más sobre las API. Y cada vez más empresas están viendo las API como productos y están constantemente al pendiente de los gerentes de productos API. Entonces, ¿qué pasa con las API que realmente necesitas conocer? En primer lugar, es necesario conocer la solicitud y respuesta a diversos métodos HTTP. El punto final, ¿qué elementos constituyen un mensaje? ¿ Qué es un encabezado, qué es la autenticación? ¿ Qué es una carga útil? Qué es una API RESTful, y así sucesivamente. Entonces en las próximas conferencias vamos a ver exactamente esto para que al final de esta sección, así tendrás una comprensión bastante buena de una API. Gracias por escuchar y esperar verte en la siguiente clase. 5. Qué es una API: Empecemos con la pregunta fundamental. ¿Qué es una API? Api es sinónimo de interfaz de programación de aplicaciones. Y en su forma más simple, es básicamente una tecnología que ayuda a conectarse a diferentes sistemas. Y API hace que la vida de los desarrolladores sea más simple y fácil. Es, les ayuda a conectarse a sistemas de terceros y a utilizar su funcionalidad. En lugar de construir la funcionalidad desde cero, ayuda a las empresas a ir al mercado más rápido. Ayuda a las empresas a aprovechar los servicios existentes y así sucesivamente. Ejemplo muy popular que he citado anteriormente es el uso de aplicaciones de ride-sharing. Y aplicaciones de uso compartido. Necesitas mapas para ayudar a los escritores, así como a los consumidores, saber fácilmente dónde colorea una manera particular y cómo llegar a un destino una cierta cantidad de tiempo. Y por lo tanto, en lugar de construir una aplicación de mapas desde cero, consumen API de un proveedor externo, por ejemplo, Google, que puedan usar la aplicación Maps forma parte del viaje existente del usuario. Gracias por escuchar y esperar verte en la siguiente clase. 6. Cómo trabajar APIs en APIs: Entonces, ¿cómo funcionan las API? Una analogía popular que se utiliza para explicar las API es la analogía del restaurante. Digamos que tienes hambre, vas a un restaurante y quieres pedir tu comida favorita. Por lo que empiezas a buscar en el menú las diversas opciones disponibles para ti. Entonces escoges una opción específica que realmente necesitas. El requerimiento a. Cuanto mayor, el mesero luego va al backend, le dice tu petición a la cocina, y la cocina procesa toda tu comida, y luego se la devuelve al mesero, que luego viene y te devuelve la comida y estás feliz y empieza a comer. Apis, en cierto sentido, trabajan en base a esta arquitectura de solicitud y respuesta. Entonces si quieres ver tu video favorito, ¿qué haces? Vas a YouTube y das una solicitud a YouTube para reproducir tu video favorito. Youtube luego vuelve a la base de datos, recupera el video que realmente solicitaste y te responde de vuelta con ese video. Entonces hay una solicitud y una respuesta en la analogía del restaurante, un menú es igual a la documentación de la API que te dice claramente de qué es capaz la API. Entonces la petición es lo que le das al sistema, y luego la respuesta de lo mayor es igual a la respuesta de YouTube. Por lo que esencialmente, en su nivel fundamental y API consiste en solicitud y una respuesta. ¿ Qué contiene cada solicitud y qué contiene cada respuesta? ¿ A qué vas a mirar en las próximas conferencias? Gracias por escuchar. 7. Qué son los servicios web: Ahora si te enteraste de las API, es posible que también hayas oído hablar de los servicios web. ¿ Qué son los servicios web? ¿ Son diferentes a las API? Echemos un vistazo a ellos. Ahora, el servicio web es una API a la que se puede acceder a través de Internet. Pero una API también puede ser una interfaz entre dos sistemas que no están conectados a través de Internet. Todos los servicios web o API, pero todas las API no tienen por qué ser necesariamente servicios web. Ahora, cuando se trata de servicios web, existen mayoritariamente algunos tipos diferentes de servicios web. Jabón, JSON, RPC, XML, RPC RESTful API. Ahora, en lugar de mirar todos estos diferentes servicios en detalle, lo que preferiría hacer es enfocarme en RESTful API porque eso es más común y eso es algo que habrías escuchado una y otra vez. Y si realmente entiendes la API RESTful, probablemente serías capaz de recoger cualquier tipo diferente de API en el futuro también fácilmente en así que en las siguientes clases, Echemos un vistazo a RESTful API con más detalle. 8. Qué es una API REST: Ahora veamos qué es una API RESTful. Ahora descanso es sinónimo de Transferencia Estatal Representacional. Se trata de un estilo arquitectónico que guía a los desarrolladores a construir API. Por lo que es un conjunto de reglas que ayudan a los desarrolladores a construir API. Ahora. Y su nivel más simple de arquitectura de arresto en fue una solicitud para ser enviada a través de Internet utilizando métodos HTTP para obtener una respuesta. Ya has visto esto usando varios ejemplos antes. Por ejemplo, si te estás haciendo una solicitud, la app de YouTube, hiciste esa solicitud a través de internet y obtienes una respuesta como video. Ahora bien, ¿qué elementos constituyen mensaje de solicitud? ¿ Cuáles son los diferentes tipos de métodos HTTP, y cómo se ve una respuesta? Estas son las cosas que vamos a ver las secciones entrantes. 9. Elementos de una API: Entendamos ahora lo que constituía los elementos de una API. Y hay cinco elementos diferentes de una API, que es un método de respuesta de solicitud, encabezado y un cuerpo. Ahora, ¿qué significan cada uno de estos elementos? Estamos viendo una clase entrante. 10. Métodos de HTTP: Ahora veamos los diferentes métodos HTTP. Por lo que cuando haces una solicitud o Internet, utilizas métodos HTTP para obtener la respuesta relevante. Ahora veamos la analogía del restaurante. Has ido al restaurante y lo primero que haces es conseguir el menú del mesero. Ahora, el acto de conseguir es un método. De igual manera utilizar diferentes métodos para obtener la respuesta adecuada del servicio web. Por lo que los métodos HTTP comunes son post, GET, PUT, y delete. Ahora si estás familiarizado con la base de datos, estarías familiarizado con la analogía de la multitud donde c significa crear nuestros cuatro R3, tú para la actualización, D para eliminar. Ahora de manera similar, cada uno de estos métodos HTTP realiza estas funciones. Por ejemplo, si usas el método GET, estás solicitando información al servidor, si estás usando el método post, esencialmente estás creando una nueva entrada en la plata. Si estás usando el método put, estás actualizando o creando un nuevo recurso en el servidor. Y si estás usando el método delete, esencialmente borrando una entrada del sur. Estos son los diferentes métodos que puedes usar a través de la arquitectura API resto. Gracias por escuchar y esperar verte próxima clase. 11. Solicitud y respuesta de API: Ahora vamos a entender sobre la solicitud. Ahora, como vimos antes, haces una solicitud usando el método HTTP para obtener una respuesta. Entonces, ¿cómo enviaste una solicitud? Enviaste una solicitud a una URL y además envías el método que quieres hacer. Se quiere conseguir, poner un post o eliminar no envía la información de encabezado y cuerpo como parte de ese mensaje. Y cada vez que hablas de URL, ¿qué hace la clase de URL? Ya constituye el protocolo. En nuestro caso, es protocolo heterotópico. Lo estamos enviando a través de Internet. Ahora. El segundo es el dominio, el sitio web donde se alojan los recursos. Y tercero es el camino. Y finalmente es el endpoint que realmente queremos golpear que van a ser múltiples puntos finales diferentes que devuelven respuestas diferentes. Por lo que típicamente una URL consiste en estas cosas. Por lo que se hace solicitud a una URL con un método específico, con un cuerpo y un encabezado. Ahora veamos una respuesta. Digamos que hiciste una solicitud, puedes solicitar y vas a obtener una respuesta de la API ahora solicitud y una respuesta de casi lo mismo, excepto que una respuesta no tiene una URL o un método. En cambio tiene cabecera códigos de estado, y el cuerpo, cuando haces una solicitud, lo que necesitas saber es, tiene solicitudes siendo exitosas, ¿obtuviste lo que buscas o ha habido algún error? Por lo que son estados indefinidos que obtendrás en la respuesta de la cual podrás saber si tu solicitud ha sido exitosa o no. Y entonces tendrá un encabezado y un cuerpo. Echemos un vistazo a eso en las siguientes secciones. 12. Datos (carga de pago): Hemos visto que cuerpo forma parte de la solicitud y respuesta. ¿ A qué nos referimos por cuerpo? Por cuerpo, nos referimos esencialmente a los datos que envías a la API y también obtienes de la API. También se llama carga útil. Entonces si eres desarrollador te dice que ¿a qué le gusta o se ve? Esencialmente lo que quieren decir es que quieren que veas cuáles son los datos que alguna vez has enviado o recibido de la API. ¿ Por qué necesitas enviar datos a través de tu API? Digamos que estás iniciando sesión en tu aplicación web. El nombre de usuario y contraseña son los datos que envías para la aplicación te reconozca y te autentifique e inicie sesión en la aplicación. Por lo que los datos suelen enviarse en formato JSON o XML. Ahora bien, estas son formas de representar tu carga útil. Entonces, ¿qué significa JSON? Json significa JavaScript Object Notation esencialmente utiliza objetos para definir los datos dentro de ellos. En el día a día se define usando pares de valor clave como este. Y también puede representar matrices usando corchetes como este. Alternativamente, también puede representar datos en el formulario XML. Xml usa etiquetas de apertura y cierre y luego valores dentro de eso, y usa el anidamiento para representar matrices. Entonces estos son dos formatos populares en los que solicita una respuesta centrum que tengo de tu API. Proporcionaré enlaces a recursos para saber más sobre JSON y XML para los efectos de este curso para ser bueno para que sepas que la solicitud y respuesta se envían usando el cuerpo también se llama la carga útil y el formato en el que el ascenso, típicamente nuestro JSON y XML. 13. Encabezado de la API: Bienvenidos a la última parte que son los encabezados. Pero cuando envías tu solicitud a la API, puede ser API dar la respuesta a ella está pidiendo. Por lo que no debería ser tan un cheque si tienes derecho a solicitar información. Entonces de eso se trata la autenticación. Por lo que puede enviar algunas informaciones adicionales utilizando el encabezado del mensaje. Por lo que vamos a discutir sobre dos información importante que usted manda. Una es autenticación, la otra es Content-Type. Hablemos primero de la autenticación. Hay algunos esquemas de autenticación diferentes que están disponibles son populares son la autenticación básica, que esencialmente está usando su nombre de usuario y inicio de sesión para autenticarse. El otro es clave API, donde envías clave API única junto con tu solicitud. Y tercero es por ahora discutir sobre cómo funcionan estos diferentes mecanismos de autenticación está más allá del alcance de este curso. Estos mecanismos de autenticación permiten al servidor comprobar sus credenciales y confirmar si realmente pueden responder con los datos solicitados o no. El siguiente es el tipo de contenido. Por lo que vimos antes que se puede enviar una carga útil en diferentes formatos, por ejemplo, JSON y XML cuando el cliente envía una solicitud, también puede decirle al servidor qué tipo de datos se puede aceptar eso. Por lo que también podemos usar el encabezado para mencionar en qué tipo de contenido se encuentran los datos. El encabezado se puede utilizar para suministrar información adicional como esta también. Por lo que eso forma todos los elementos clave de una API. Gracias por escuchar y esperar verte próxima clase. 14. Lección extra: webhooks: Hola a todos. En esta sección de bonos, veamos lo que es un webhook. Por lo que los webhooks se comporta ligeramente diferente a lo que se comportan las API tradicionales. A veces se les llama como una API inversa. Y como gerente de producto, es importante que entiendas qué son los ganchos web y dónde podrías usarlos realmente. Entonces veamos eso usando un escenario. Digamos que uno integrado con PayPal. Cada vez que alguien te hace un pago en papel, deseas que PayPal te notifique para que puedas enviar el producto. Ahora hay dos formas en que puedes hacer eso. Uno como puedes seguir comprobando PayPal, si se ha recibido o no un pago. Paypal tiene API. Puedes suscribirte, puedes golpear esa API, obtener la lista de respuestas y ver si hay algún nuevo pago que se haya recuperado. Ahora, podrías hacerlo varias veces y cada vez que encuentres un nuevo pago en la respuesta, podrías entonces activar tu propio proceso interno con el fin de enviar ese producto. Pero el proceso de comprobación de la API, solicitar una respuesta a la API varias veces es un desperdicio de ancho de banda, así como de su sistema y fuentes. Y no solo eso, muchos de los proveedores de API van a tener límites en el número de veces que realmente puedes golpear a la API. Entonces cada vez que vas a estar golpeando la API, estás consumiendo tus límites. Entonces esa no es una manera ideal, en realidad sería mejor si PayPal mismo puede decirte dónde se ha recibido un pago para que luego puedas asegurarte de que la entrega de los productos. Aquí sin embargo, eres el tercero que depende de PayPal. Paypal tiene tantos consumidores diferentes. ¿ Cómo pueden entonces notificar eficientemente y consumidor específico frecuentemente evento. Entonces ahí es donde sus ganchos entran en escena donde los libros son muy útiles cuando hay un cambio en el estado o evento cambiante. Y se espera una notificación de un proveedor específico basado en el cual se desea dar inicio a su propio proceso. Por lo que PayPal tendría una interfaz webhook donde dirías a qué URL tiene que enviar PayPal la notificación de evento específico para que luego puedas esperar hasta que se haya recibido la notificación y luego arrancar tu propio proceso. Entonces, a diferencia de una API donde solicitas y luego obtienes una respuesta en un gancho web, ese es un evento y luego basado en qué respuesta se proporciona entonces. Por lo que normalmente será un mensaje de publicación que PayPal haría a la especificación HTTP endpoint. Y de eso espero que se tratara todo. Para leer más sobre los ganchos web. He adjuntado algunos recursos en las lecciones. Por favor siéntase libre de revisarlos. 15. La mentalidad de productos de API: Y este vaso, vamos a entender por qué es importante entrar en la mentalidad de mirar las API como productos y tipo de proyectos. Ahora antes de hacer eso, empecemos con mirar cómo las APIs generalmente un muro en la empresa. Ahora, toma un ejemplo de los hoteles Hilton. Tienen un montón de hoteles en todo el mundo. Normalmente lo que podría haber pasado es que un cliente podría ponerse en contacto y preguntar al empleado del hotel si, si puede reservar una de las habitaciones por un cierto periodo de tiempo. Entonces lo que haría la persona al final del mostrador, podría hacer es obtener una lista de todas las habitaciones disponibles, dar su información de precios, hacer una reserva y luego obtener el pago del cliente. Ahora, como la tecnología habría evolucionado, tienes múltiples canales diferentes evolucionando como aplicación web para Hilton Hotels y por aplicación. Ahora, en lugar de replicar el mismo proceso para cada uno de estos diferentes sistemas, lo que podrían haber hecho es una api de plataforma identificó cuatro API y API diferentes para obtener la lista de todas las salas disponibles y API para obtener el información de precios para las habitaciones y API para hacer una reserva y luego obtener el pago del usuario. Por lo que estas cuatro API podrían haber sido consumidas por estos diferentes canales. Y por lo tanto, existe el beneficio de crear API internas para el grupo Hilton de negocios hoteleros. Y alguien inteligente desde dentro de la empresa podría haber descubierto que hay otras empresas que podrían aprovechar las API para Hilton Hotels y luego reservar habitaciones para Hilton a través de esas aplicaciones. Ahora empresas como Expedia consumen estas API y luego permiten a los usuarios reservar hoteles a través de su aplicación. Por lo que no ha tenido más ingresos a través de una nueva oportunidad de negocio. Ahora soy más desarrolladores creativos y posiblemente podrían estar buscando permitir a los usuarios utilizar Amazon Echo o la asistencia sabia de Google para hacer una reserva de hotel a través del uso de zippy. Y así hay un nuevo canal y las oportunidades de negocio están explorando múltiples. Entonces ese es el beneficio, exponiendo las API a un mercado más amplio. Y por eso, porque las API, lo que todas las necesidades específicas de un conjunto específico de usuarios finales y también brindan la oportunidad de impulsar el crecimiento del negocio. Deberían mirarse los productos y no los proyectos. Tradicionalmente, cómo han evolucionado las API, porque están construidas para audiencias internas. La mayoría de las veces, se los mira como proyectos. Ya sabes, la necesidad del negocio, tus casos de uso son más o menos fijos. Por lo que comienzas a construir las API con un objetivo final específico en mente. Por lo que siempre miras a construirlas como proyectos. No estás pensando en un 100 clientes diferentes con múltiples casos de uso. No obstante, eso suele ser lo que va a suceder una vez que exponga estas API al usuario final. Si no lo haces, esta mentalidad de producto, lo que podría pasar es que podrías construir una API como proyecto, y luego exponer todas las API a los desarrolladores de terceros. Pero tal vez encuentres que ninguno de ellos realmente lo ha usado porque realmente no tenían necesidad de ello. Y por lo tanto todos sus esfuerzos se han ido por el desagüe. Por lo tanto, es importante ver las API como productos. Por lo que hay que empezar de entender a los usuarios. ¿ Qué tipo de problemas tienen estos desarrolladores? ¿ Cómo podría realmente ayudarlos mi API y luego llegar a un pequeño MVP de una API, lanzarla al mercado, validarla, probarla y el nitrato y seguir mejorando. Por lo que necesitas meterte en la mente del producto para tener verdaderamente éxito en el lanzamiento de tu producto API. 16. Ciclo de vida de API First y API: En esta clase, entendamos qué se entiende por primera estrategia API y también veamos un ciclo de vida típico de un producto API. ¿ Y qué es la API primero? Ahora todos hemos acordado en la clase anterior que necesitas salir de la mentalidad del proyecto. Estoy llegando a la mentalidad del producto a la hora de construir API para usuarios de terceros. Entonces, si tienes 20 API internas, no puedes simplemente exponer las 20 al usuario final. Por lo que pueden quedar sin usar porque los usuarios finales tal vez no tengan realmente necesidad de estas API. Por lo que API primera estrategia esencialmente significa que comenzar con diseño y el contrato de API antes de implementar realmente la API. Y luego intenta validar si esta API realmente va a ser útil para nuestros usuarios finales. Lo que esto significa es que vas a obtener retroalimentación temprana. Vas a identificar brechas en tus procesos de negocio o tus detalles técnicos. Y podrás arreglarlos rápidamente antes de implementar realmente la API. Y como estás empezando por entender a los usuarios y mirarla como una API para el usuario final primero, tú más a menudo que no, tendrás una API que en realidad será utilizada y adoptada por un usuario final. Entonces con ese entendimiento, ¿cómo se ve el típico ciclo de vida del producto API? Entonces, empecemos con el diseño. Entonces seguirás adelante e implementarás un MVP. Por lo que construirás TI, seguridad, probada, liberarla, monitorizarla, y luego me lo comeré, y todo el proceso se repite de nuevo. Por lo que podría ver que cómo es más o menos similar a cómo un ciclo de vida de producto tradicional también es en un mundo ágil. 17. Crea un producto mínimo viable: Ahora veamos la importancia de MVP cuando se trata de productos API, cuando se trata de gestionar productos tradicionales, la importancia de los MSP, bien entendidos. No creo que los productos API y cualquier diferente cuando vas al mercado la primera vez con una API es importante mirarlo en términos de MVP, porque es importante que vayas al mercado rápido con una propuesta de valor que los desarrolladores me encantaría adoptar y luego aprender de ella, y luego lo comercio lo antes posible. Por ejemplo, si su L, podría tener tantos procesos de negocio backend. Por ejemplo, podrías tener API, API internas para obtener la lista de todos los restaurantes en una ubicación específica. Podrías obtener lista de todos los restaurantes que son de cinco estrellas y superiores, obtener lista de restaurantes con las opiniones de los usuarios en una ubicación específica y así sucesivamente. Pero, ¿es importante exponer una API con toda esa complejidad? O es importante ir al mercado con una solución menos compleja, pero realmente no deberíamos ser valiosos. Por ejemplo, si vas a exponer una API que proporciona una lista de restaurantes por ubicación, es importante dar todos los diversos parámetros de consulta que es importante dar todas las respuestas en la carga útil, tal vez no. Por lo que es importante que veas lo que es un MVP para que puedas ir al mercado más rápido y cómo lo adoptan los desarrolladores para luego aprender de él y probar nitrato en él. Recuerda que todos estos son experimentos y no todos tus experimentos van a tener éxito. Algunos de tus MVP pueden desvanecerse. Pero recuerda que MVP con éxitos podría abrir oportunidades de negocio totalmente nuevas y póliza un ir al mercado y obtener datos, mejor será un argumento para dar justificación empresarial para inversiones adicionales, ¿no? Lectura por esa parte. 18. Diseño de productos en la API, desarrollo y lanzamiento: Y ahora que hemos mirado la importancia de un MVP para un producto API, Veamos cómo realmente diseñas algo y lanzas un producto API. Los pasos involucrados son ligeramente diferentes en comparación con el producto tradicional. Tradicionalmente, ¿qué harías si es posible te gustaría construir un prototipo clicable usando algo así como en revisión de una aplicación frontend y luego mostrarlo a algunos de tus usuarios o usarlo, revisarlo antes en realidad vas adelante y construyes la aplicación. Entonces, cuando se trata de API, es posible que quieras hacer algo similar a eso. Entonces el documento de diseño, el documento de especificación API, es lo que ayuda con nosotros a diseñar la API de primera mano, donde se puede decir cuáles serán las especificaciones de la API, ¿cuál será la solicitud y respuesta? ¿ Cuál será el endpoint al que golpearás? Cuáles son los diversos parámetros de consulta que soportarás y demás. Ahora, con el documento de diseño listo, entonces podría tenerlo revisado para asegurarse que proporcionará Databricks uniformes evita que sí hace una API conforme a nuestras API anteriores es convenciones de nomenclatura impares, el versionado , todo consistente con nuestros estándares. ¿ Estás usando algún jargón? ¿ Qué tipo de nomenclatura estamos haciendo en realidad? ¿ Estamos usando estructuras anidadas para una futura extensibilidad? Estaré usando enums, dos booleanos para nuevas propiedades. Por ejemplo, si la respuesta tiene una columna de estado que dice un sí o no como lo es un estado binario, preferirías ser éxito o fracaso si es necesario en el futuro en un estado intermediario está llamando a rana en progreso, así, así sucesivamente y así sucesivamente. Por lo que el proceso de revisión va a ser muy útil para iterar realmente en la API diseñada para hacerla amplia antes de que realmente se implemente. Y una vez que hayas hecho eso, el siguiente paso sería hacer pruebas de usuario, donde usarás esto para probar con un conjunto selecto de grupos para comprobar si la API realmente va a ser utilizable. Es posible que también desee construir una API y exponer la primera versión para uso experimental. Una forma típica de usar esto sería el pie de perro. Es posible que desee liberarlo a sus usuarios internos. Por ejemplo, tu personal primero, pide a todos los empleados de tu personal que comiencen a usar la API y proporcionen comentarios. Y también montamos entrevistas algunos otros desarrolladores de terceros con los que tienes relaciones comerciales. Desarrolladores de terceros para entender realmente a la API le falta algo. Una vez que tuviste todos estos y yo iteré build the API, podrías seguir adelante con una beta de lanzamiento temprano lanzada a todos los usuarios. O podría hacer liberación cerrada donde poner la API detrás de una puerta y permitir el acceso a un conjunto específico de usuarios para entender más sobre cómo realmente la usan. Si realmente quieres hacer más cambios antes de ir realmente por un lanzamiento de disponibilidad general. Entonces ese es más o menos el ciclo de vida. Y eso es algo que hay que tener en cuenta. Siempre que empezamos a construir una nueva API. 19. Cómo dar adopción a través de la experiencia intuitiva de desarrollador: Una vez que tengas un MVP por ahí, el siguiente paso en el ciclo de vida del producto API es impulsar la adopción, medir. Es el uso, y luego lo cambio. ¿ Y cómo se impulsa la adopción? Es el primer paso clave para impulsar la adopción es tener un gran portal de desarrolladores. Porque tu usuario final para la API al menos es tu desarrollador de terceros. Por lo que es importante para ellos poder entender todo sobre la API fácilmente mirando la documentación. Por lo que necesitas tener una gran documentación, grandes guías de usuario, un entorno de sandbox para que lo prueben. Ejemplo, casos de uso, quizá foros. Hay tantas maneras diferentes que necesitas pensar en ello en cuanto a cómo puedes hacer la vida de tu desarrollador fácil. lo que los desarrolladores normalmente no van a pasar mucho tiempo en su portal de desarrolladores inicialmente cuando está investigando sobre la API. Significa ser muy sencillo y fácil e intuitivo de entender para que puedan ponerse en marcha lo antes posible, tal vez incluso 30 minutos. Por lo que es importante invertir mucho tiempo en hacer que la experiencia del desarrollador sea genial. Por lo que necesitas tener un gran portal de desarrolladores Gracias a ti próximos años y necesitas enfocarte en evangelizar tu API. ¿ A qué me refiero con eso? Si crees que solo vas a construir una API, ponla ahí fuera, y la gente va a entrar y adoptarla. No va a pasar. Necesitas enviar la propuesta de valor apropiadamente herramienta los dashboards para que DID pueda, estarían realmente interesados en usar la API. No importa. El API tiene una API interna o una API externa. Aunque tus desarrolladores, aunque haya usuarios internos para la API que estás construyendo dentro la organización es importante para vender la propuesta de valor, ¿verdad? Para que lo puedan adoptar. Por lo que únete a conferencias, realiza webinars, saca el mensaje para vender la propuesta de valor de la manera correcta a tus usuarios. Y una vez que tengas suficiente adopción, mide, cómo la gente la está usando. ¿ En realidad estamos satisfaciendo las necesidades del usuario? ¿ Es lo suficientemente seguro? Por lo que tratando de entender y abastecer para medir métricas. Entonces, ¿cómo mides las métricas y cómo sabes qué medir? Por lo que es necesario definir los indicadores clave de desempeño. Y eso es lo que vamos a ver en la siguiente sección. 20. Métricas que importa: Por lo que el siguiente paso en la gestión efectiva de los productos de VM es medir métricas que realmente importan. Por lo que para hacer eso, es necesario identificar los indicadores clave de rendimiento de API. Entonces, primero, piensa en cuál es realmente el propósito de tu API? Esta es su API destinada a impulsar ingresos directos a su negocio. Por ejemplo, las personas hacen compras a través de la API por lo que esperas que tus ingresos mensuales aumenten realmente, o se trata de impulsar los ingresos directos? Donde al exponer una API que proporciona las reseñas de un restaurante específico, esperas más visitas de clientes a la página del restaurante en tu sitio web, y por lo tanto, más reservas al restaurante desde tu sitio web, y por lo tanto el incrementos de ingresos. Por lo que aquí la métrica podría ser un número de nuevos usuarios registrados a través la API o número de uso de restaurante a través de la API y así sucesivamente. ¿ Cuál es el propósito de su API para impulsar nuevas oportunidades de negocio? O se trata de aumentar tu tamaño de usuarios de desarrolladores o aumentar el tamaño de tu ecosistema de partners. Por lo que es importante que entiendas realmente cuál es tu impulsor de negocio clave para esta API y por lo tanto, luego determinar la métrica apropiada no Star. Y el otro podría ser también hacer un seguimiento del uso de la API. Por ejemplo, nuestros desarrolladores usan la API de la forma en que se pretende, cuántas veces están llamando a la API, ¿qué parámetros de consulta están utilizando más? ¿ Y obtienen la respuesta que buscan con más frecuencia que no? Y también realizar un seguimiento de la experiencia del desarrollador a través del portal. Ellos obtendrán registro y obtendrán la clave API rápidamente. ¿ Son capaces de levantarse y correr más rápido? Por lo que el seguimiento de todas estas métricas te va a dar la retroalimentación que realmente necesitas para hacer una, identificar las API que realmente lograron una métrica de negocio y por lo tanto enfocar iterando y mejorando la API para mirar también al desarrollador experiencia. ¿ Cómo puedes hacer que la experiencia de desarrollador sea más agradable? ¿ Qué parte del viaje define más fricción? Y luego también te ayudará con tus estrategias de monetización. Por lo que es importante obtener retroalimentación temprana para que puedas realizar un seguimiento de estas métricas para una nueva API, va a ser importante. Va a ser difícil obtener esa retroalimentación que necesitan. Por lo que necesitas usar tus conexiones para conseguir que esos primeros desarrolladores estén a bordo. Entonces ahí es donde realmente entra en panorama el evangelismo de la API. Organizar conferencias de hackathons, llegar a tus socios y demás son formas en las que realmente puedes empezar la adopción de API. 21. Versionado de API: Hola a todos. Veamos ahora el versionado de API. Ahora, cuando se trata de Versionar, es más o menos sencillo para los productos tradicionales. Y muchas veces cada vez que sueltas una nueva versión a los usuarios finales, es posible que ni siquiera noten que se ha hecho aversión porque las versiones suelen ser pequeñas y frecuentes. Entonces uno de los principios clave de Vijay para hacer lanzamientos frecuentes y pequeños para que puedas aprender de los usuarios. Apis sería muy difícil para ti hacer nuevas versiones de API. Esto se debe a que piense en cómo funcionan las API. Se libera una API al tercero y un tercero uno o más terceros habrían integrado a la API si estás haciendo una nueva versión de la API, lo que significa que todos los usuarios externos existentes tendrían que hacer código cambia para que ahora puedan apuntar a la nueva versión de la API. Entonces, tan cuidadoso proceso de pensamiento se debe pagar. Antes de lanzar una nueva versión de una API. Podrías elegir mejoras a una API existente siempre y cuando ninguna de ellas esté rompiendo cambios. Entonces, ¿cuándo deberías considerar una nueva versión? Por lo que sería cuando haya un cambio de ruptura sus consumidores de la API debido a mejoras en la API. ¿ A qué me refiero con romper cambios? Por lo que estás enviando algunos detalles en tu respuesta de API. Ahora vas a encontrar que la carga útil esté demasiado hinchada y estás pensando que tal vez necesitas eliminar algunas de las respuestas. Si estás quitando eso, podría haber mucho del QBI, muchos desarrolladores de terceros que podrían estar esperando la respuesta muy disponible en la API. Si lo estás quitando, entonces atrévete proceso podría realmente verse afectado. O digamos que hiciste un cambio en el URI. Por lo que todos estos están rompiendo cambios. Y si tuvieras que hacerlas, tienes que lanzar una nueva versión de la API. Antes de hacer una nueva versión de la API, también necesitas pensar, cuánto tiempo vas a soportar la versión anterior de la API. Porque cada versión va a tener costos de mantenimiento asociados a ella. Entonces, así que necesitas, necesitas entonces mirar los datos para ver cuántos consumidores están usando la versión anterior de la API y ¿están dispuestos a hacer la transición a la nueva API? Por lo que necesitas proporcionar una línea de tiempo suficiente durante cuánto tiempo estarás apoyando esa versión anterior en el APA que tengan información suficiente por adelantado para elegir migrar a la nueva versión o no. Y así considerando la importancia del versionado y la API, también es importante comunicarse por adelantado y claramente a todos sus consumidores. Siempre que razone que estás lavando, debes usar tu portal de desarrolladores y todos los demás canales que están disponibles para ti, para los desarrolladores de terceros. Entonces en que todos están suficientemente conscientes, la otra cosa importante en la que hay que pensar es ¿cómo se nombra la versión? Ahora, hay diferentes estándares que los diferentes desarrolladores de API siguen. A algunos de ellos les gustaría tener el número de versión como parte del URI, digamos que es la versión 2 o la versión 20. A algunos de ellos les gustaría tener una fecha como parte del URI. Algunos de ellos quisieran proporcionar la información de la versión como parte del encabezado. Por lo que no hay una sola manera ni forma correcta de hacerlo. Pero la forma más común, la forma más fácil sería proporcionar el número de versión real como parte del URI. Entonces, sea cual sea el formato que, sea cual sea el estándar que realmente sigues, necesitas tener la consistencia en todas las API de todas las API que realmente manejas. Porque los desarrolladores se acostumbrarán a cierta manera. Y si estás siguiendo, proporcionando diferentes tipos de advertencia y no sabrían buscar la última versión y cómo consumirlas. 22. Pites una API en la poorly de diseñar: Veamos ahora las trampas de una API mal diseñada y desarrollada. Muchas empresas lanzan API sin entender realmente las necesidades de los usuarios de las necesidades de los desarrolladores en el mercado, a lo que esto lleva es a una API mal diseñada que sea menos adoptada o no hay adopción alta. Por lo que mucho del esfuerzo y costo que se gastó en diseñar la API, exponer la API va por el desagüe. El modo de solucionarlo será que los desarrolladores comiencen a diseñar y desarrollar una nueva API y a cablearla de nuevo a un sistema back-end y lanzando una nueva versión de la API, que es un ejercicio costoso. Lo que lo empeoraría es que si tuvieras alguna adopción para la versión anterior de la API, eso podría significar que podrías tener que mover a algunos de estos usuarios a la nueva versión de la API, o podrías decidir apoyar la anterior versión de la API, todas las cuales se van a sumar a tu dolor y costos. Ahora otro escollo común es exponer una API con un sistema back-end mal diseñado. sistema back-end podría tener procesos de negocio de arquitectura heredada que han evolucionado con el tiempo y no se han optimizado para eficiencias. Entonces si vas a estar exponiendo una API que va a ser menos fácilmente comprensible y adoptable y escalable. Y entonces va a llevar a una adopción muy pobre. Por lo tanto, la única forma de solucionar esto es comenzar por entender las necesidades del usuario y luego diseñar API bien definida por adelantado. 23. El valor de una API bien pensado: ¿ Cuáles son los valores de API bien definida? Ahora, API es que si vas al mercado con una API bien definida y que se adopta en gran medida, dará lugar a nuevas oportunidades de negocio para tu empresa ahora creado un desarrolladores de terceros podrían usar tus API de formas que nunca imaginaste fue posible. Por ejemplo, cuando se expuso la API de Maps, realmente no habrían pensado en un caso de uso de una aplicación de entrega de restaurantes usando mapas para realmente mostrar cuando la entrega está pasando, ¿verdad? Ahora. Esa es una nueva oportunidad de negocio para los Desarrolladores de Mapas y crea mayores ingresos. Y otra cosa es que una API bien definida, fácilmente comprensible va a tener efectos de networking. Desarrolladores externos adicionales van a buscar la adopción exitosa de un caso de uso y luego entrar, crear otros múltiples casos de uso. Entonces vas a tener aumento en los ingresos, nuevas oportunidades de negocio desarrolladas, y tu negocio va a crecer mucho más. 24. Quién crea el equipo de API: Hola a todos. En esta sección, veamos la importancia del equipo de API y quién forma el equipo de API. Por lo que el equipo de API típicamente consiste en el gerente de producto de API, el arquitecto de API, los desarrolladores de API y el evangelista de APA. Ahora en muchas organizaciones pueden no ser un equipo de API dedicado, pero cada vez más, las organizaciones están comprendiendo la importancia de tener un equipo de API dedicado, tener la mentalidad del producto y construir API como productos. Por lo que los gerentes de productos APA son pieza clave de este equipo. En las siguientes conferencias, aprendiste que entiendes específicamente acerca los roles y responsabilidades de un gerente de producto API, de los arquitectos, desarrolladores, y de la APA sin valuele. Gracias por escuchar y esperar verte en la siguiente clase. 25. Introducción a las estrategias de precios de API: Ahora pasemos a una parte muy importante de la gestión de productos API, que son las estrategias de precios de APA. ¿ Cómo monetiza su API? En primer lugar, ¿qué es la monetización? Por decirlo de forma sencilla, se trata de ganar dinero a través de tu API. Y la forma en que haces dinero, podría ser muy diferente. Podría ser que cada vez que alguien tiene que usar tu API, necesitan pagarte y por lo tanto haces dinero. Entonces es un ingreso diádico. O podría ser que cada vez que usan una API y hacen una compra de tu producto o servicio, realmente haces dinero. Por lo que podría haber implicaciones directas de ingresos para la API. Ese es un modelo de negocio. El otro podría ser, podrías ofrecer una API de forma gratuita porque va a beneficiar indirectamente a tu negocio. Por ejemplo, Google y Facebook podrían ofrecer uso de sus API porque obtienen más datos de clientes, lo que no les va a ayudar directamente a proporcionar servicios más personalizados a sus clientes. Por lo que de igual manera, podría ser varias otras formas indirectas en las que el uso de API podría afectar a su negocio. Entonces esencialmente eso es lo que está diciendo la monetización. En las próximas secciones, vamos a discutir algunas de las estrategias de precios populares para las API. 26. Opciones de precios de API: Cuando se trata de estrategias de monetización para API son esencialmente cuatro. Por lo que normalmente hay cuatro maneras diferentes en que las empresas precian las API. Uno es gratis, no hay precio para usar en el trabajo la API. El siguiente es que el desarrollador paga por la API. El tercero es que se le paga al desarrollador por usar la API. Y la última son las oportunidades de negocio indirectas. 27. Stakeholders de la economía de API: Por lo que antes de mirar las estrategias de precios específicas para una API, primero entendamos quiénes son los stakeholders en la economía de la API. Entonces primero, este es el proveedor de API. Esencialmente este es el negocio ha decidido exponer un montón de API a terceros usuarios, y el interesado en realidad determina el precio. Y vienen a continuación, los desarrolladores de API que en realidad consumen esta API y construyen algo a partir de ella y lo ofrecen a sus usuarios finales. Entonces, por último, en realidad son los usuarios finales los que se beneficiaron con la API. No necesariamente ven la API, pero son realmente los beneficiarios reales de la funcionalidad que ofrece la API. Para que tu estrategia de monetización sea verdaderamente exitosa, es importante que la API sea beneficiosa para los tres de estos diferentes stakeholders. Entonces, ¿cuál es el precio que determinaste para la API no solo debe ser beneficioso para tu negocio, sino que también debe ser sustentable para el desarrollador de API para que sea capaz de proporcionar un valor a este usuario final. Entonces si dices que tu API va a costar cantidad X, pero el valor real que los desarrolladores de terceros realmente obtienen es menor a X cantidad que en realidad te está pagando. No es como estrategia de monetización sustentable. Por lo tanto, ten en cuenta a estos tres diferentes stakeholders cuando pienses en las diversas opciones de precios que tienes delante para tu API. 28. Precios de API gratis: Ahora veamos la primera opción que es gratuita. ¿ Por qué una empresa ofrecería una API de forma gratuita? Por lo que ofrecerías una API de forma gratuita por variedad de razones. Podría ser que quieras aumentar la adopción. Por lo que cerca de crecer nuevo en el mercado, no habría nadie que pudiera ver el valor en la API lo suficiente. Por lo que tal vez quieras probar el caso de uso para la API y por lo tanto ofreces un árbol inicialmente, o podrías querer retener a los consumidores que es una mayor competencia. Por lo que quieres ofrecer servicios de API para que cada vez más socios que realmente se asocien contigo en lugar de competir. O podría ser que estás obteniendo algo beneficio dag. Por ejemplo, los inicios de sesión sociales que están disponibles, como go, puedes iniciar sesión a través de Facebook, registrarte a través de Google y así sucesivamente. Estas API a menudo se ofrecen de forma gratuita. Pero cuál es el beneficio que obtienen estas empresas es más datos de uso de clientes. De lo que esto beneficia a los desarrolladores externos es porque ofrece una forma muy fácil de identificar al usuario y simplificar el proceso de inicio de sesión. Por lo que es un ganar-ganar para las tres partes dentro de la economía API. Por lo que hay casos de uso legítimos para cuando podrías considerar ofrecer tu API de forma gratuita. 29. Pases de precios en API para desarrolladores: El siguiente modelo de monetización es donde el desarrollador realmente paga por el uso de la API. Para que este modelo solo tenga éxito devaluar que el desarrollador obtiene por uso de la API en realidad debería ser más de lo que el APA realmente está siendo preciado. Eso es sólo entonces los desarrolladores que en realidad consideran pagar por la API. De nuevo hay, diferentes formas en las que puedes precio y API. Por ejemplo, esto podría ser un modelo de pago por uso, podría ser un modelo freemium, podría ser un modelo por niveles, o podría ser un modelo basado en cuotas de transacción. Entonces cuando dices que el modelo de pago se desarrolla solo paga cuando realmente usan la API. Entonces cada vez que usan API que realmente pegan en la montura, un buen ejemplo para esto puede ser una aplicación de verificación de crédito. Entonces cuando solicitas un préstamo para el banco, banco realmente hace una llamada a la agencia de cheques de crédito y ellos pagan cierta cuota por ese cheque de crédito específico. El otro podría ser un modelo de negocio freemium donde ofreces de forma gratuita una repentina funcionalidades de API de bajo valor. Si bien si quieren reales funcionalidades premium son diferentes puntos finales los cuales son de mayor valor. Tendrán que pagar realmente por esa API. Esto es similar a cómo las aplicaciones tradicionales ofrecen los modelos Freemium. Esto es para conseguir que las personas adopten su API específica sobre acostumbrados a ella y les gusta, y en realidad van por una versión de pago. El tercero es un modelo por niveles donde, donde podrías ponerlo aquí diciendo que cada por 10 mil hits diarios, en realidad puedes pagar tanto. Si lo usas entre diez mil, quince mil hits diarios, en realidad tendrás una pagada esta cantidad. O si excedes los niveles para los que realmente te suscribiste, tendrás que pagar una cantidad realmente alta. Entonces, para que puedas arrancar el precio de alguna manera. Y los desarrolladores podrían realmente escoger y elegir el trato que creen que sería cuál sería su cuota de uso real. Ahora el último es un modelo basado en cuota de transacción. ¿ De dónde conseguirás una comisión por la transacción? Paypal o Stripe o cualquiera de la aplicación de pagos. Un buen ejemplo. Entonces cada vez que golpeas una API de Pagos e realizas una transacción y obtienes un cierto porcentaje de cuota por la transacción. Por lo que estos son los diferentes modelos en los que se puede valorar la API. Y no son las únicas formas en las que realmente puedes ponerlas en precio, pero estas son algunas de las formas populares. 30. Desarrollador de precios en la API: El siguiente modelo de monetización es donde se paga al desarrollador por usar la API. Por lo que este modelo podría ser utilizado donde usted como proveedor de API en realidad se beneficia más por la API está siendo utilizada por desarrollador de terceros. Por lo que necesitas incentivar a los desarrolladores para que usen la API y por lo tanto pagas la API. Por lo que algunos ejemplos para esto es viajar agregadores de agregadores de vuelos o agregadores hoteleros se benefician en realidad de este modelo de precios. Por ejemplo, cada vez que se realiza una venta a través de la API específica IS un hotel las opera y realmente proporciona una comisión. Desarrolladores porque esencialmente están actuando como agentes impulsando más ventas a mi hotel. Por lo que otro modelo popular es el modelo de referencia o afiliado. Podría ser consciente de que podría ser un usuario afiliado de Amazon puede conducir compras de productos en Amazon, obtienes una tarifa por cada referencia. De igual manera, si hay más tráfico o más compras realizadas en tu sitio web a través de sitios web afiliados, podrías incentivar a los desarrolladores pagándoles. Algunos de los ejemplos populares son, ya sabes, Google y Google AdWords, compañías de seguros y agentes, o en sitios de trabajo como Monster.com y así sucesivamente.