Gerenciamento de produtos API

1. Introdução: Oi a todos, estou indo. Sou gerente de produto com sede no Reino Unido. De todos os produtos gerenciados na minha carreira. O mais desafiador deles foram os produtos de API. E mais e mais empresas estão começando a analisar as APIs como produtos. Por exemplo, se você visitar uma empresa no mundo, seja o PayPal stripe, Facebook, Twitter ou qualquer empresa. Você encontrará regras para produtos de API ou gerentes de produtos experientes em desenvolvedores. Mas como você se prepara para esses papéis? O que foi desafiador para mim quando eu estava começando foi a falta de um recurso centralizado que falasse sobre APIs especificamente para gerentes de produto. Agora, neste curso, minha tentativa simplificar APIs e torná-lo mais compreensível para qualquer pessoa que comece recentemente no mundo das APIs e do gerenciamento de produtos. Então, como, como eu estruturei esse curso? Primeiro, começaremos entendendo alguns exemplos de produtos de API. Em seguida, entraremos nos fundamentos das APIs. Como as APIs realmente funcionam? Qual é a tecnologia por trás das APIs? Também veremos um exemplo de uso de uma API e por meio do Postman. E, em seguida, entraremos no gerenciamento de um produto de uma API. Como entrar na mentalidade do produto da API. Qual é o ciclo de vida de uma API? Como ir em frente e criar, medir e expandir produtos de API. E, em seguida, entraremos nas funções e responsabilidades da equipe da API, bem como do gerente de produto da API. E, finalmente, veremos o modelo de negócios. Como as APIs devem ser precificadas? Quais são as diferentes opções de preços disponíveis para nós? Espero que, no final deste curso, você tenha um bom entendimento do que são APIs, por que elas devem ser vistas como produtos e como gerenciá-las como produtos. Obrigado por ouvir e espero vê-lo do outro lado. 2. O caso para produtos de API: Olá a todos. Esperemos que você tenha uma compreensão justa o suficiente do que é uma API e do que a tecnologia de TI está por trás dela, e quais são os diferentes tipos de APIs e assim por diante. Vejamos agora o caso de um produto de API. Por que você deve começar a analisar as APIs como um produto no início, já o setor de software estava evoluindo tradicionalmente aplicativos e criou aplicativos de regra padrão. Você pode ter um sistema de recursos humanos. Você pode ter um sistema para gerenciar a folha de pagamento. Você pode ter um sistema para gerenciar vendas. Você pode ter um sistema para gerenciar marketing e assim por diante. Então, cada um desses sistemas onde essencialmente aplicações em silos, mas eventualmente havia uma necessidade para essas aplicações para falar uns com os outros, e, portanto, interfaces estavam sendo desenvolvidas. E então as equipes perceberam que, em vez de criar os aplicativos primeiro e depois pensar em interfaces, elas devem começar com uma primeira abordagem de API, vamos tentar criar microsserviços que podem ser consumidos por outros aplicativos e assim por diante. Portanto, você tinha APIs privadas em que as diferentes equipes dentro da empresa consomem essas APIs para que os sistemas possam solicitar informações de outros aplicativos facilmente. Agora, eventualmente, empresas mais inteligentes descobriram que as APIs são muito mais do que as deles. E as APIs podem ser vistas como produtos em si. Por exemplo, você pode usar seu Google Maps como um aplicativo autônomo no navegador ou no celular. No entanto, o Google também tem uma API, Maps API, que está disponível para desenvolvedores públicos podem usar este mapa para API e, em seguida, criar produtos inovadores em torno deles. Por exemplo, seus aplicativos de compartilhamento de viagens, como o Uber e o Ola usaram a API do Google Maps para oferecer experiências intuitivas aos clientes. Outro bom exemplo é o PayPal. Você pode usar o PayPal para enviar dinheiro, receber pagamentos e assim por diante. Mas as pessoas também tem API que as empresas podem usar para integrar pagamentos PayPal em seu site através do qual os usuários podem começar a comprar o lado esquerdo. E o PayPal ganha muito dinheiro através dessas APIs. Dizem que empresas como a Expedia fazem pelo menos 90% da receita apenas com APIs. Ebay definido para fazer cerca de 60 por cento de sua receita de APIs. Portanto, as APIs precisam ser vistas como produtos em si mesmas, onde você entende a necessidade específica do cliente e cria APIs que possam atender a essa jornada do cliente. Então é aí que as APIs precisam ser vistas como produtos. E a gestão de produtos APA aparece. Obrigado por ouvir e espero vê-lo na próxima aula. 3. Exemplos de produtos de API: Oi a todos e bem-vindos a esta classe e puxar, Eu quero dar-lhe uma visão geral rápida do que é um produto API. Eu não vou fazer isso mostrando alguns exemplos de produtos de API populares. E, obviamente, vamos falar sobre a tecnologia por trás da API. O que é uma API e como ela funciona? E o que é gerenciamento de produtos de API e assim por diante nas próximas classes. Mas antes de realmente entrar nos detalhes disso, eu acho que é importante para todos nós ter uma compreensão compartilhada do que é um produto API. Então, vejamos o PayPal, por exemplo. Então, o que é PayPal? Paypal é um produto que nos ajuda a fazer pagamentos ou receber pagamentos de alguém. Então eles têm um belo produto baseado na interface do usuário que muitos de vocês podem ter usado. Também tem APIs. Então eles fornecem, para que ela olhasse para o site deles. Há uma seção chamada desenvolvedor, e se você clicar nisso, que fornece todas as APIs que desenvolvedores de terceiros podem usar para integrar em pagos, pagos. Então, se você clicar, então ele tem documentação para as diferentes APIs. E se você clicar na API, você pode ver quais são as diferentes APIs sobre como, como você realmente faz login no painel? Como você obtém as credenciais para acessar o token? Como você faz as chamadas de API? Eles têm um sandbox, essencialmente é um ambiente de teste onde você pode testar a API e eles têm alguns exemplos. Portanto, tudo isso destina-se a ajudar desenvolvedores de terceiros a entender mais sobre as APIs, os recursos das APIs e, em seguida, começar a consumir as APIs. Então esse é um exemplo. O outro grande exemplo é Twilio. Twilio é muito conhecido por seus produtos baseados em API. Novamente, qualquer aplicativo popular produto Pablo que você vê nos dias de hoje teria uma seção especificamente destinada para desenvolvedores. E Twilio também tem uma seção para Delta Force e tem algumas de suas APIs populares. Por exemplo, ele tem uma API do WhatsApp. Vamos clicar e ver o que realmente tem. Então, de novo, é uma documentação. Ele tem ordenadamente diz como você começar como um desenvolvedor? Como você pode começar a usar esta API? Quais são as referências, quais são os guias e tutoriais para você começar a usar esta API? E isso essencialmente nos ajuda a começar a consumir facilmente a API. Da mesma forma, eles têm vários produtos que foram todos expostos como APIs. Eles também têm kits de desenvolvimento de software. vez, estas são bibliotecas que, como um desenvolvedor, você poderia facilmente usar e começar a criar os aplicativos. E só eles têm kits de desenvolvimento separados para Android, iOS e assim por diante. Então, vamos continuar e olhar para a API do Google. Então, como você deve saber, o Google Maps, por exemplo, é um produto que qualquer pessoa pode usar gratuitamente. Então você instala o aplicativo em seu telefone ou você pode abrir o aplicativo Google Maps em seu navegador e, em seguida, começar a usar o aplicativo Mapas. No entanto, o Google também fornece uma API para desenvolvedores terceirizados começarem a usá-los. Por exemplo, aplicativos de compartilhamento de viagens como Ola Uber usam a API do Google Maps para fornecer integração com o Maps como parte de seu próprio aplicativo. Então qualquer um pode começar a usar este KPI. Então eles têm um site chamado Developers dot google.com. Então, isso é especificamente destinado para desenvolvedores. Queremos usar o caso de uso específico de produtos do Google. E agora vamos olhar para a documentação aqui. E, novamente, isso também nos diz com que facilidade você pode começar usando a API. Como você configura o seu projeto? Como você habilita a API ou o SDK? Como você obtém a chave de API, e assim por diante e assim por diante. E, em seguida, eles também dizem como, como escolher uma API. Então, se você quiser adicionar um mapa a um aplicativo Android, use o SDK do Maps para Android. Da mesma forma, eles têm diferentes casos de uso e as APIs específicas que você pode realmente usar para esses diferentes casos de uso. Vamos também olhar para uma API específica e d, d, digamos que você tem a API Roads. Vejamos a API mais próxima. Então este é um ponto final de API e as estradas mais próximas esta API irá, este é o ponto final que você vai acertar. Estes são os parâmetros de consulta que você usará para realmente filtrar seus resultados com base no que sua necessidade. E esta é a chave de API que você enviará. Portanto, esta é a API específica que você usará. E esta documentação nos diz quais são exemplos diferentes. Se você queria usar isso através de Java, Python, Ruby, Go e carteiros e assim por diante, também pode executar isso em carteiros, que é um aplicativo muito popular para testar suas APIs. Veremos como fazer isso nas aulas posteriores. Então é assim que a resposta parece e assim por diante. Então, essencialmente, o que vimos nesses três produtos diferentes é que mesmo que cada uma dessas empresas tenha produtos muito bem sucedidos em si, elas também têm muito cuidado em expor APIs a desenvolvedores de terceiros. Portanto, muitas vezes essas empresas teriam gerentes de produto dedicados que gerenciam essas experiências em torno dessas APIs. Porque os desenvolvedores que vão usar esta API são os usuários reais deste produto. Os gerentes de produto precisam realmente entender o que é que os desenvolvedores querem? Quais são os pontos de dor deles? Quais são os casos de uso específicos para os quais eles poderiam usar uma API? Construído não, e não apenas criar APIs, mas também criar a experiência do desenvolvedor e o objeto. Essencialmente, apresentando documentação, apresentando exemplos, apresentando ambientes de sandbox, essencialmente, apresentando todos os detalhes de suporte para ajudar os desenvolvedores a começar a trabalhar rapidamente. Então é isso que o produto API é. Essencialmente é que não é apenas a API, mas também a experiência do desenvolvedor em torno dela. Esperemos que isso tenha lhe dado uma boa compreensão do que são os produtos da API. Não se preocupe se ainda não estiver totalmente confiante. Não se preocupe se você ainda se sentir um pouco enquanto nos movemos pelo curso. Assim, você teria uma compreensão muito melhor das APIs e do gerenciamento de produtos de API. Obrigado por ouvir e espero vê-lo na próxima aula. 4. What&why por que um gerente de produtos deve saber sobre APIs: Como gerente de produto, você estará invariavelmente envolvido no uso de APIs de uma mãe real. A seguir estão os três cenários diferentes em que você pode estar envolvido no uso de APIs. Em primeiro lugar, você pode estar lidando com APIs internas que diferentes equipes de sua organização usam para casos de uso compartilhados. Em segundo lugar, você pode estar consumindo uma API de terceiros como parte de sua experiência de produto. Por exemplo, se for um gestor de produtos Uber, pode estar a utilizar a API do Google Maps para os seus próprios casos de utilização. Em terceiro lugar, alternativamente, se você for um gerente de produto do Google, você pode estar expondo uma API do Maps para que ela possa ser consumida por desenvolvedores de terceiros, como a Uber, a fim de usar casos de uso próprios. Portanto, é importante que os gerentes de produto entendam mais sobre APIs. E cada vez mais empresas estão olhando para APIs como produtos e eles estão constantemente à procura de gerentes de produtos de API. Então, o que é sobre as APIs que você realmente precisa saber sobre? Em primeiro lugar, você precisa saber sobre a solicitação e resposta a vários métodos HTTP. O ponto final, que elementos constituem uma mensagem? O que é um cabeçalho, o que é autenticação? O que é uma carga útil? O que é uma API RESTful e assim por diante. Então, nas próximas palestras, vamos olhar exatamente isso para que no final desta seção, assim você terá uma boa compreensão de uma API. Obrigado por ouvir e espero vê-lo na próxima aula. 5. O que é uma API: Vamos começar com a questão fundamental. O que é uma API? Api significa interface de programação de aplicativos. E em sua forma mais simples, é basicamente uma tecnologia que ajuda a se conectar a diferentes sistemas. E a API torna a vida dos desenvolvedores mais simples e fácil. Ele, ele os ajuda a se conectar a sistemas de terceiros e utilizar sua funcionalidade. Em vez de criar a funcionalidade a partir do zero, ele ajuda as empresas a entrar no mercado mais rapidamente. Ele ajuda as empresas a alavancar os serviços existentes e assim por diante. Exemplo muito popular que citei anteriormente é o uso de aplicativos de compartilhamento de passeio. E aplicativos de compartilhamento de viagens. Você precisa de mapas para ajudar os escritores, bem como os consumidores, facilmente saber onde uma determinada maneira cores e como chegar a um destino uma certa quantidade de tempo. E, portanto, em vez de construir um aplicativo de mapas a partir do zero, eles consomem API de um provedor de terceiros, por exemplo, o Google, que eles possam usar o aplicativo Mapas faz parte da jornada do usuário existente. Obrigado por ouvir e espero vê-lo na próxima aula. 6. Como funcionar Como as APIs: Então, como as APIs funcionam? Uma analogia popular que é usada para explicar APIs é a analogia do restaurante. Digamos que você está com fome, você vai a um restaurante e você quer encomendar sua comida favorita. Então você começa a olhar para o menu para as várias opções disponíveis para você. Então você escolhe uma opção específica que você realmente precisa. O pedido para. Quanto maior, o garçom vai para o backend, diz o seu pedido para a cozinha, ea cozinha processa toda a sua comida, e então ele devolve para o garçom, que então vem e devolve a comida para você e você está feliz e começar a comer. As APIS, em certo sentido, funcionam com base nessa arquitetura de solicitação e resposta. Então, se você quiser ver seu vídeo favorito, o que você faz? Você vai ao YouTube e dá um pedido ao YouTube para reproduzir seu vídeo favorito. Em seguida, o Youtube volta para o banco de dados, obtém o vídeo que você realmente solicitou e responde para você de volta com esse vídeo. Portanto, há um pedido e uma resposta na analogia do restaurante, um menu é igual à documentação da API que diz claramente do que a API é capaz. Então o pedido é o que você dá ao sistema, e então a resposta do maior é igual à resposta do YouTube. Portanto, essencialmente, em seu nível fundamental e API consiste em solicitação e uma resposta. O que cada solicitação contém e o que cada resposta contém? O que você vai olhar nas próximas palestras? Obrigado por ouvir. 7. O que são serviços web: Agora, se você ouviu falar sobre APIs, você também pode ter ouvido falar sobre serviços da Web. O que são serviços da Web? Eles são diferentes das APIs? Vamos olhar para eles. Agora, o serviço Web é uma API que você pode acessar pela Internet. Mas uma API também pode ser uma interface entre dois sistemas que não estão conectados pela Internet. Todos os serviços Web ou APIs, mas todas as APIs não precisam necessariamente ser serviços Web. Agora, quando se trata de serviços web, existem principalmente alguns tipos diferentes de serviços web. Soap, JSON, RPC, XML, API RESTful RPC. Agora, em vez de olhar para todos esses diferentes serviços em detalhes, o que eu prefiro fazer é focar na API RESTful porque isso é mais comum e isso é algo que você teria ouvido repetidamente. E se você realmente entender a API RESTful, você provavelmente seria capaz de pegar qualquer tipo diferente de API no futuro, bem facilmente em assim nas seguintes classes, Vamos olhar para RESTful API em mais detalhes. 8. O que é uma API REEST: Agora vamos ver o que é uma API RESTful. Agora descanso significa Transferência Estadual Representacional. É um estilo arquitetônico que orienta os desenvolvedores a criar APIs. Portanto, é um conjunto de regras que ajudam os desenvolvedores a criar APIs. Agora. E seu nível mais simples de arquitetura de prisão em era um pedido para ser enviado pela Internet usando métodos HTTP para obter uma resposta. Você já viu isso usando vários exemplos antes. Por exemplo, se você estiver fazendo uma solicitação para você, o aplicativo do YouTube, você fez essa solicitação pela Internet e obterá uma resposta como um vídeo. Agora, quais elementos constituem mensagem de solicitação? Quais são os diferentes tipos de métodos HTTP, e como é que uma resposta se parece? Estas são as coisas que vamos olhar para as seções recebidas. 9. Elementos de uma API: Vamos agora entender o que constituiu os elementos de uma API. E há cinco elementos diferentes de uma API, que é um método de resposta de solicitação, cabeçalho e um corpo. Agora, o que cada um desses elementos significa? Estamos olhando para uma aula chegando. 10. Métodos HTTP: Agora vamos olhar para os diferentes métodos HTTP. Então, quando você faz uma solicitação ou a Internet, você usa métodos HTTP para obter a resposta relevante. Agora vamos olhar para a analogia do restaurante. Você foi ao restaurante e a primeira coisa que você faz é pegar o menu do garçom. Agora, o ato de conseguir é um método. Da mesma forma, use métodos diferentes para obter a resposta apropriada do serviço web. Assim, os métodos HTTP comuns são post, GET, PUT e delete. Agora, se você está familiarizado com banco de dados, você estaria familiarizado com analogia multidão onde c significa criar nossos quatro R3, você para atualização, D para excluir. Agora, da mesma forma, cada um desses métodos HTTP executar essas funções. Por exemplo, se você usar o método GET, você está solicitando informações do servidor, se você estiver usando o método post, você está essencialmente criando uma nova entrada na prata. Se você estiver usando o método put, você está atualizando ou criando um novo recurso no servidor. E se você estiver usando o método delete, essencialmente excluindo uma entrada do sul. Estes são os diferentes métodos que você pode usar através da arquitetura de API restante. Obrigado por ouvir e espero vê-lo na próxima aula. 11. Solicitação e resposta de API: Agora vamos entender sobre o pedido. Agora, como vimos anteriormente, você faz uma solicitação usando o método HTTP para obter uma resposta. Então, como você enviou um pedido? Você enviou uma solicitação para um URL e você também envia o método que você deseja fazer. Você quer obter, colocar um post ou excluir não envia o cabeçalho e informações do corpo como parte dessa mensagem. E sempre que você fala sobre URL, o que a classe URL você faz? Você já constitui o protocolo. No nosso caso, é um protocolo heterotópico. Estamos a enviá-lo através da Internet. Agora. O segundo é o domínio, o site onde os recursos estão hospedados. E o terceiro é o caminho. E, finalmente, é o endpoint que realmente queremos atingir que serão vários endpoints diferentes que retornam respostas diferentes. Portanto, normalmente uma URL consiste nessas coisas. Portanto, a solicitação é feita para uma URL com um método específico, com um corpo e um cabeçalho. Agora vamos olhar para uma resposta. Digamos que você fez uma solicitação, você pode solicitar e você vai obter uma resposta da API agora solicitação e uma resposta praticamente a mesma, exceto que uma resposta não tem um URL ou um método. Em vez disso, ele tem códigos de status cabeçalho , eo corpo, quando você faz uma solicitação, o que você precisa saber é, tem solicitações sendo bem-sucedidas, você conseguiu o que você está procurando ou houve algum erro? Então, eles são status indefinidos que você receberá na resposta a partir do qual você pode saber se sua solicitação foi bem-sucedida ou não. E então terá um cabeçalho e um corpo. Vejamos isso nas próximas seções. 12. Data(payload ): Vimos que o corpo faz parte do pedido e da resposta. O que queremos dizer com corpo? Por corpo, essencialmente nos referimos aos dados que você envia para a API e também obtém a partir da API. Também é chamado de carga útil. Então, se você é um desenvolvedor diz a você que o que ele atrai ou parece? Essencialmente o que eles querem dizer é que eles querem que você veja quais são os dados que você já enviou ou recebeu da API. Por que você precisa enviar dados através de sua API? Digamos que você está fazendo login em seu aplicativo web. O nome de usuário e senha são os dados que você envia para o aplicativo o reconheça e autentique e faça login no aplicativo. Portanto, os dados são normalmente enviados em formato JSON ou XML. Agora, estas são formas de representar a sua carga útil. Então, o que significa JSON? Json significa JavaScript Object Notation essencialmente usa objetos para definir os dados dentro deles. No dia-a-dia é definido usando pares de valores-chave como este. E também pode representar matrizes usando colchetes como este. Como alternativa, você também pode representar dados no formato XML. Xml usa marcas de abertura e fechamento e, em seguida, valores dentro disso, e ele usa aninhamento para representar matrizes. Então estes são dois formatos populares em que solicita uma resposta centrum que eu tenho da sua API. Vou fornecer links para recursos para saber mais sobre JSON e XML para os fins deste curso para ser bom para você saber que solicitação e resposta são enviados usando o corpo também é chamado de carga útil e o formato em que a subida, tipicamente nosso JSON e XML. 13. Cabeçalho de API: Bem-vindo à última parte que é os cabeçalhos. Mas quando você enviar o seu pedido para a API, pode ser API dar a resposta a ela está pedindo. Portanto, não deve ser tão um cheque se você tem o direito de solicitar informações. Então é disso que se trata a autenticação. Assim, você pode enviar algumas informações adicionais usando o cabeçalho da mensagem. Então vamos discutir sobre duas informações importantes que você enviar. Uma é autenticação, a outra é Content-Type. Vamos primeiro falar sobre autenticação. Existem alguns esquemas de autenticação diferentes que estão disponíveis são populares os autenticação básica, que é essencialmente usando seu nome de usuário e login para autenticar. A outra é a chave de API, onde você envia a chave de API exclusiva junto com sua solicitação. E o terceiro é, por enquanto, discutir como esses diferentes mecanismos de autenticação funcionam está além do escopo deste curso. Esses mecanismos de autenticação permitem que o servidor verifique suas credenciais e confirme se eles podem realmente responder com os dados solicitados ou não. O próximo é o tipo de conteúdo. Então vimos anteriormente que você pode enviar uma carga em diferentes formatos, por exemplo, JSON e XML quando o cliente envia uma solicitação, ele também pode dizer ao servidor que tipo de dados você pode aceitar isso. Então, também podemos usar o cabeçalho para mencionar que tipo de tipo de conteúdo os dados estão em. O cabeçalho pode ser usado para fornecer informações adicionais como esta também. Então isso forma todos os elementos-chave de uma API. Obrigado por ouvir e espero vê-lo na próxima aula. 14. Aula de bônus — Webhooks: Olá a todos. Nesta seção de bônus, vamos ver o que é um webhook. Assim, webhooks se comporta um pouco diferente do que as APIs tradicionais se comportam. Eles às vezes são chamados como uma API reversa. E, como gerente de produtos, é importante que você entenda o que são os ganchos da web e onde você pode realmente usá-los. Então vamos olhar para isso usando um cenário. Digamos que um integrado com PayPal. Toda vez que alguém faz um pagamento para você em papel, você quer que o PayPal o notifique para que você possa enviar o produto. Agora, há duas maneiras de fazer isso. Um como você pode continuar verificando PayPal, se um pagamento foi recebido ou não. Paypal tem APIs. Você pode se inscrever, você pode bater essa API, obter a lista de respostas e ver se há algum novo pagamento que foi recuperado. Agora, você pode fazer isso várias vezes e sempre que encontrar um novo pagamento na resposta, você pode então acionar seu próprio processo interno para enviar esse produto. Mas o processo de verificação da API, solicitar uma resposta à API várias vezes é um desperdício de largura de banda, bem como seu sistema e fontes. E não apenas isso, muitos dos provedores de API terão limites no número de vezes que você pode realmente acertar a API. Então, toda vez que você vai estar atingindo a API, você está consumindo seus limites. Então, essa não é uma maneira ideal, seria realmente melhor se PayPal pode se dizer onde um pagamento foi recebido para que você possa em seguida, certificar-se de que a entrega dos produtos. Aqui, porém, você é o terceiro que depende do PayPal. Paypal tem tantos consumidores diferentes. Como eles podem, em seguida, notificar eficientemente e consumidor específico muitas vezes evento. Então é aí que seus ganchos entram em imagem onde os livros são muito úteis quando há uma mudança no status ou mudança de evento. E uma notificação é esperada de um provedor específico com base no qual você deseja iniciar seu próprio processo. Assim, o PayPal teria uma interface webhook onde você diria qual URL que o PayPal tem que enviar a notificação de evento específico para que você possa esperar até que a notificação tenha sido recebida e, em seguida, iniciar seu próprio processo. Então, ao contrário de uma API onde você solicita e, em seguida, obter uma resposta em um gancho da web, que é um evento e, em seguida, com base em qual resposta é fornecida. Então, normalmente, será uma mensagem de post que o PayPal faria para o endpoint HTTP especificação. E isso é o que eu espero que tenha sido tudo. Para ler mais sobre os ganchos da web. Juntei alguns recursos nas lições. Por favor, sinta-se à vontade para verificá-los. 15. A mentalidade do produto API: E este vidro, vamos entender por que é importante entrar na mentalidade de olhar para APIs como produtos e tipos de projetos. Agora, antes de fazer isso, vamos começar com a análise como APIs geralmente um muro na empresa. Agora, tome um exemplo dos hotéis Hilton. Eles têm um monte de hotéis em todo o mundo. Normalmente, o que poderia ter acontecido é um cliente pode entrar em contato e perguntar ao funcionário do hotel se, se ele pode reservar um dos quartos por um determinado período de tempo. Então, o que a pessoa no final do balcão poderia fazer é obter uma lista de todos os quartos disponíveis, dar suas informações de preços, fazer uma reserva e, em seguida, obter o pagamento do cliente. Agora, como a tecnologia teria evoluído, você tem vários canais diferentes evoluindo como aplicação web para Hilton Hotels e por aplicativo. Agora, em vez de replicar o mesmo processo para cada um desses sistemas diferentes, o que eles poderiam ter feito é uma API de plataforma identificou quatro APIs e API diferentes para obter a lista de todas as salas disponíveis e API para obter o informações de preços para os quartos e API para fazer uma reserva e, em seguida, obter o pagamento do usuário. Então essas quatro APIs poderiam ter sido consumidas por esses diferentes canais. E, portanto, há um benefício de criar APIs internas para o grupo Hilton de negócios hoteleiros. E alguém inteligente de dentro da empresa pode agora ter descoberto que existem outras empresas que poderiam alavancar as APIs para os hotéis Hilton e depois reservar quartos para a Hilton através desses aplicativos. Agora, empresas como a Expedia consomem essas APIs e , em seguida, permitem que os usuários reservem hotéis através de sua aplicação. Portanto, não tem mais receita através de uma nova oportunidade de negócio. Agora eu sou mais desenvolvedores criativos e eles poderiam possivelmente estar olhando para permitir que os usuários para usar Amazon Echo ou Google assistência sábia para fazer reservas de hotel usando zippy. E então há um novo canal e as oportunidades de negócios estão explorando várias. Então esse é o benefício, expor APIs a um mercado mais amplo. E é por isso que, porque as APIs, todas as necessidades específicas de um conjunto específico de usuários finais e também oferecem a oportunidade de impulsionar o crescimento dos negócios. Eles devem ser examinados para produtos e não para projetos. Tradicionalmente, como as APIs evoluíram, pois são criadas para públicos internos. Na maioria das vezes, eles são vistos como projetos. Você sabe, a necessidade do negócio, seus casos de uso são praticamente corrigidos. Assim, você começa a criar as APIs com uma meta final específica em mente. Então você sempre olha para construí-los como projetos. Você não está pensando em 100 clientes diferentes com vários casos de uso. No entanto, isso é normalmente o que acontecerá quando você expor essas APIs ao usuário final. Se você não fizer isso, essa mentalidade do produto, o que pode acontecer é que você pode criar uma API como um projeto e, em seguida, você expõe todas as APIs para os desenvolvedores de terceiros. Mas você pode descobrir que nenhum deles realmente usou porque eles realmente não precisavam dele. E, portanto, todos os seus esforços foram pelo ralo. Portanto, é importante olhar para APIs como produtos. Então você precisa começar a entender os usuários. Que tipo de problemas esses desenvolvedores têm? Como poderia minha API é realmente ajudá-los e, em seguida, chegar a um pequeno MVP de uma API, lançá-lo no mercado, validado, testá-lo e o nitrato e continuar melhorando. Então você precisa entrar na mente do produto para ser realmente bem sucedido no lançamento do seu produto API. 16. API primeiro e ciclo de vida de API: Nesta classe, vamos entender o que significa a primeira estratégia de API e também olhar para um ciclo de vida típico de um produto API. E o que é a API primeiro? Agora todos concordamos na classe anterior que você precisa sair da mentalidade do projeto. Estou chegando à mentalidade do produto quando se trata de criar APIs para usuários terceirizados. Então, se você tem 20 APIs internas, você não pode simplesmente expor todas elas ao usuário final. Portanto, eles podem não ser usados porque os usuários finais podem realmente não ter uma necessidade dessas APIs. Portanto, a primeira estratégia API significa essencialmente que começar com projeto e contrato de API antes de realmente implementar a API. E, em seguida, tente validar se esta API realmente vai ser útil para nossos usuários finais. O que isso significa é que você vai receber feedback antecipado. Você identificará lacunas nos processos de negócios ou nos detalhes técnicos. E você poderá corrigi-los rapidamente antes de realmente implementar a API. E como você está começando com a compreensão dos usuários e olhando para ela como uma API para o usuário final primeiro, você geralmente terá uma API que será usada e adotada por um usuário final. Então, com esse entendimento, como é o típico ciclo de vida do produto API? Então vamos começar com o design. Então você vai em frente e implementar um MVP. Então você vai criar TI, segurança, testado, liberá-lo, monitorá-lo, e então eu negociá-lo, e todo o processo se repete novamente. Então, você pode ver que é praticamente semelhante a como um ciclo de vida tradicional do produto também é em um mundo ágil. 17. Como criar um produto viável mínimo: Agora vamos olhar para a importância do MVP quando se trata de produtos API, quando se trata de gerenciar produtos tradicionais, a importância dos MSPs, bem compreendida. Eu não acho que produtos API e qualquer diferente quando você está indo para o mercado pela primeira vez com uma API é importante olhar para ele em termos de MVP, porque é importante para você ir ao mercado rapidamente com uma proposta de valor que os desenvolvedores adoraria adotar e, em seguida, aprender com ele, e então eu negociá-lo o mais cedo possível. Por exemplo, se o seu L, você pode ter tantos processos de negócios back-end. Por exemplo, você pode ter APIs, APIs internas para obter a lista de todos os restaurantes em um local específico. Você pode obter lista de todos os restaurantes que são cinco estrelas e acima, obter lista de restaurantes com os comentários de usuários em um local específico e assim por diante. Mas é importante expor uma API com toda essa complexidade? Ou é importante ir ao mercado com uma solução menos complexa, mas não devemos realmente ser valiosos. Por exemplo, se você vai expor uma API que fornece uma lista de restaurantes por localização, é importante dar todos os vários parâmetros de consulta que são importantes para dar todas as respostas na carga útil, talvez não. Portanto, é importante para você olhar para o que é um MVP para que você possa ir ao mercado mais rápido e como os desenvolvedores adotá-lo e, em seguida, aprender com ele e testar nitrato nele. Lembre-se que todos estes são experimentos e nem todos os seus experimentos vão ter sucesso. Alguns dos seus MVPs podem desaparecer. Mas lembre-se que MVP com sucesso poderia abrir novas oportunidades de negócios e política de ir ao mercado e obter dados, o melhor será um argumento para dar justificação comercial para investimentos adicionais, certo? Lendo nessa parte. 18. Design de produtos de API, desenvolvimento e lançamento: E agora que analisamos a importância de um MVP para um produto de API, vamos ver como você realmente projetar algo e lançar um produto de API. As etapas envolvidas são ligeiramente diferentes quando comparadas ao produto tradicional. Tradicionalmente, o que você faria se fosse possível criar um protótipo clicável usando algo como na revisão de um aplicativo frontend e, em seguida, mostrá-lo a alguns de seus usuários ou usá-lo, revisá-lo antes você realmente ir em frente e construir o aplicativo. Então, quando se trata de APIs, você pode querer fazer algo semelhante a isso. Então, o documento de design, o documento de especificação da API, é o que nos ajuda a projetar a API em primeira mão, onde você pode dizer quais serão as especificações da API, qual será a solicitação e resposta? Qual será o ponto final que você vai acertar? Quais são os vários parâmetros de consulta que você suportará e assim por diante. Agora, com o documento de design pronto, você poderia então tê-lo revisado para garantir que ele irá fornecer Databricks uniforme impede que ele faz uma API em conformidade com nossas APIs anteriores é convenções de nomenclatura ímpar, o controle de versão , tudo consistente com os nossos padrões. Você está usando algum jargão? Que tipo de nome estamos fazendo? Estamos usando estruturas aninhadas para extensibilidade futura? Vou usar enums, dois booleanos para novas propriedades. Por exemplo, se a resposta tem uma coluna de status que diz um sim ou não como um estado binário é, você preferiria ser sucesso ou fracasso se necessário no futuro em um estado intermediário está chamando sapo em andamento, assim, assim por diante e assim por diante. Então, o processo de revisão vai ser muito útil para realmente iterar na API projetada para obtê-lo amplo antes de realmente ser implementado. E uma vez que você tenha feito isso, o próximo passo seria fazer testes de usuário, onde você usará isso para testar com um conjunto selecionado de grupos para verificar se a API realmente vai ser utilizável. Você também pode querer criar uma API e expor a primeira versão para uso experimental. Uma maneira típica de usar isso seria comida de cachorro. Você pode querer liberá-lo para seus usuários internos. Por exemplo, sua equipe primeiro, peça a todos os funcionários que comecem a usar a API e forneçam feedback. Além disso, criamos entrevistas outros desenvolvedores terceirizados com quem você tem relações comerciais. Desenvolvedores de terceiros para realmente entender a API está faltando algo. Uma vez que você tinha todos estes e eu iterei construir a API, você pode continuar com uma versão beta antecipada lançada para todos os usuários. Ou você pode fazer o release fechado onde você coloca a API atrás de um portão e permitir o acesso a um conjunto específico de usuários para entender mais sobre como eles realmente usá-lo. Se você realmente deseja fazer mais alterações antes de realmente ir para uma versão de disponibilidade geral. Então, esse é praticamente o ciclo de vida. E isso é algo que você precisa ter em mente. Sempre que começamos a construir uma nova API. 19. Como conduzir a adoção através de experiência intuitiva de desenvolvedor: Depois de ter um MVP por aí, a próxima etapa no ciclo de vida do produto de API é impulsionar a adoção, a medida. É uso, e então eu troco nele. E como você dirige a adoção? É o primeiro passo chave para impulsionar a adoção é ter um ótimo portal de desenvolvedores. Como seu usuário final para a API, pelo menos, é seu desenvolvedor terceirizado. Portanto, é importante que eles sejam capazes de entender tudo sobre a API facilmente, observando a documentação. Então você precisa ter uma ótima documentação, ótimos guias do usuário, um ambiente de sandbox para testá-lo. Exemplo, casos de uso, talvez fóruns. Há tantas maneiras diferentes que você precisa pensar sobre como você pode tornar a vida do seu desenvolvedor fácil. Portanto, os desenvolvedores normalmente não vão gastar muito tempo em seu portal de desenvolvedores inicialmente quando ele está pesquisando sobre a API. Significa ser muito simples e fácil e intuitivo de entender para que eles possam começar a funcionar o mais rápido possível, talvez até 30 minutos. Portanto, é importante investir muito tempo para tornar a experiência do desenvolvedor excelente. Então você precisa ter um grande portal de desenvolvedores Graças a você no próximo ano jovens e precisa se concentrar em evangelizar sua API. O que eu quero dizer com isso? Se você acha que vai apenas construir uma API, coloque-a lá fora, e as pessoas vão simplesmente entrar e adotá-la. Isso não vai acontecer. Você precisa enviar a proposta de valor adequadamente ferramenta os painéis para que o DID possa, eles estariam realmente interessados em usar a API. Isso não importa. A API tem uma API interna ou uma API externa. Mesmo que seus desenvolvedores, mesmo que haja usuários internos para a API que você está criando dentro da organização, seja importante vender a proposta de valor, certo? Para que possam adotá-la. Então, participe de conferências, realize webinars, leve a mensagem para vender a proposta de valor da maneira certa para seus usuários. E uma vez que você tem adoção suficiente, medir, como as pessoas estão usando isso. Estamos realmente atendendo às necessidades do usuário? É seguro o suficiente? Então, tentando entender e fornecer para medir métricas. Então, como você mede métricas e como você sabe o que medir? Então você precisa definir os principais indicadores de desempenho. E é isso que vamos olhar na próxima seção. 20. Metrics que dizem o assunto: Portanto, o próximo passo no gerenciamento eficaz de produtos de VM é medir métricas que realmente importam. Então, para fazer isso, você precisa identificar os principais indicadores de desempenho da API. Então, primeiro, pense sobre qual é o propósito da sua API realmente? Esta é a sua API destinada a gerar receita direta para a sua empresa. Por exemplo, as pessoas fazem compras por meio da API então você espera que sua receita mensal aumente de fato, ou se trata de gerar receita direta? Onde, ao expor uma API que fornece as avaliações de um restaurante específico, você espera mais visitas de clientes à página do restaurante em seu site e, portanto, mais reservas para o restaurante do seu site e, portanto, o aumentos de receita. Então, aqui a métrica pode ser um número de novos usuários registrados através da API ou número de uso de restaurante através da API e assim por diante. Qual é o propósito da sua API para impulsionar novas oportunidades de negócios? Ou é sobre aumentar seu tamanho de usuários de desenvolvedores ou aumentar o tamanho de seu ecossistema de parceiros. Portanto, é importante que você realmente entenda o que é o seu principal driver de negócios para esta API e, portanto, determine a métrica apropriada e não estrela. E o outro poderia ser também rastrear o uso da API. Por exemplo, nossos desenvolvedores usam a API da maneira que ela se destina, quantas vezes eles estão chamando a API, quais parâmetros de consulta eles estão usando mais? E eles recebem a resposta que estão procurando mais frequentemente do que não? Além disso, acompanhe a experiência do desenvolvedor através do portal. Eles vão obter o registro e obter a chave API rapidamente. Eles são capazes de se levantar e correr mais rápido? Então, acompanhar todas essas métricas vai lhe dar o feedback que você realmente precisa fazer uma, identificar as APIs que realmente alcançaram uma métrica de negócios e, portanto, concentrar a iteração e melhorar a API para também olhar para o desenvolvedor experiência. Como você pode tornar a experiência do desenvolvedor mais agradável? Que parte da viagem define mais atrito? E, em seguida, ele também irá ajudá-lo com suas estratégias de monetização. Portanto, é importante obter feedback antecipado para que você possa rastrear essas métricas para uma nova API, isso será importante. Vai ser difícil obter o feedback que eles precisam. Então você precisa usar suas conexões para colocar os desenvolvedores iniciais a bordo. Então é aí que o evangelismo API realmente entra em cena. Organizar conferências hackathons, alcançar seus parceiros e assim por diante são maneiras de começar a adoção da API. 21. Versionamento de API: Olá a todos. Vamos agora olhar para o controle de versão da API. Agora, quando se trata de Versionamento, é muito simples para produtos tradicionais. E muitas vezes sempre que você lança uma nova versão para os usuários finais, eles podem nem perceber que a aversão foi feita porque as versões são muitas vezes pequenas e frequentes. Então, um dos princípios chave do Vijay para fazer lançamentos frequentes e pequenos para que você possa aprender com os usuários. Apis seria muito difícil para você fazer versões mais recentes de APIs. Isso ocorre porque pense em como as APIs funcionam. Você libera uma API para o terceiro e um ou mais terceiros teriam se integrado à API se você estiver fazendo uma nova versão da API, o que significa que todos os usuários terceirizados existentes teriam que criar código muda para que agora possam apontar para a nova versão da API. Então, processo de pensamento tão cuidadoso deve ser pago. Antes de lançar uma nova versão de uma API. Você pode escolher melhorias uma API existente, desde que nenhum deles esteja quebrando alterações. Então, quando você deve considerar uma nova versão? Assim, seria quando há uma mudança radical para seus consumidores da API devido a melhorias na API. O que eu quero dizer com quebrar mudanças? Então você está enviando alguns detalhes em sua resposta API. Agora você vai achar que a carga está muito inchada e você está pensando que talvez você precise remover algumas das respostas. Se você estiver removendo isso, pode haver muitos do QBI, muitos desenvolvedores de terceiros que podem estar esperando a resposta muito disponível na API. Se você estiver removendo-o, em seguida, ousar processo pode realmente ser afetado. Ou digamos que você fez uma mudança no URI. Então, tudo isso está quebrando mudanças. E se você tivesse que fazer isso, você deve liberar uma nova versão da API. Antes de fazer uma nova versão da API, você também precisa pensar, quanto tempo você vai suportar a versão anterior da API. Porque cada versão terá custos de manutenção associados a ela. Então, você precisa, então você precisa olhar para os dados para ver quantos consumidores estão usando a versão anterior da API e eles estão dispostos a fazer a transição para a nova API? Portanto, você precisa fornecer uma linha de tempo suficiente por quanto tempo você estará suportando essa versão anterior no APA que eles tenham informações suficientes antecipadamente para optar por migrar para a nova versão ou não. E, portanto, considerando a importância do controle de versão e da API, também é importante se comunicar com antecedência e claramente com todos os seus consumidores. Sempre que você estiver lavando, você deve usar o portal do desenvolvedor e todos os outros canais disponíveis para você, para os desenvolvedores terceirizados. Então, em todos eles estão suficientemente conscientes, a outra coisa importante que você precisa pensar é como você nomeia a versão? Agora, existem padrões diferentes que diferentes desenvolvedores de API seguem. Alguns deles gostariam de ter o número da versão como parte do URI, digamos que é a versão 2 ou a versão 20. Alguns deles gostariam de ter uma data como parte do URI. Alguns deles gostariam de fornecer as informações da versão como parte do cabeçalho. Portanto, não há uma maneira ou maneira certa de fazê-lo. Mas a maneira mais comum, a maneira mais fácil seria fornecer o número de versão real como parte do URI. Portanto, seja qual for o formato que, seja qual for o padrão que você realmente siga, você precisa ter a consistência em todas as APIs de todas as APIs que você realmente gerencia. Porque os desenvolvedores vão se acostumar a certa maneira. E se você estiver seguindo, fornecendo diferentes tipos de aviso e eles não saberiam como procurar a versão mais recente e como consumi-los. 22. Pitfalls de uma API mal projetada: Vejamos agora as armadilhas de uma API mal projetada e desenvolvida. Muitas empresas lançam APIs sem realmente entender as necessidades do usuário das necessidades do desenvolvedor no mercado, o que isso leva a uma API mal projetada que é menos adotada ou não há adoção alta. Então, muito do esforço e custo que foi gasto em projetar a API, expor a API vai para baixo. A maneira de corrigi-lo será para os desenvolvedores começarem a projetar e desenvolver uma nova API e conectá-la de volta a um sistema back-end e lançar uma nova versão da API, que é um exercício dispendioso. O que iria piorar é se você tivesse alguma adoção para a versão anterior da API, isso pode significar que você pode ter que mover alguns desses usuários para a nova versão da API, ou você pode decidir suportar o versão da API, tudo isso vai aumentar a sua dor e custos. Agora, outra armadilha comum é expor uma API com um sistema back-end mal projetado. sistema back-end pode ter processos de negócios de arquitetura legada que evoluíram ao longo do tempo e não foram otimizados para eficiência. Então, se você estiver indo para expor uma API que vai ser menos facilmente compreensível e adotável e escalável. E então isso vai levar a uma adoção muito pobre. Portanto, a única maneira de corrigir isso é começar com a compreensão das necessidades do usuário e, em seguida, projetar uma API bem definida antecipadamente. 23. O valor de uma API bem pensada: Quais são os valores da API bem definida? Agora, API é se você entrar no mercado com uma API bem definida e que é amplamente adotada, isso levará a novas oportunidades de negócios para sua empresa agora criado um desenvolvedores de terceiros poderia usar suas APIs de maneiras que você nunca imaginou era possível. Por exemplo, quando a API do Maps foi exposta, eles realmente não teriam pensado em um caso de uso de um aplicativo de entrega de restaurante usando mapas para realmente mostrar quando a entrega está acontecendo certo? Agora. Essa é uma nova oportunidade de negócio para os desenvolvedores do Mapas e cria maior receita. E outra coisa é que uma API bem definida e facilmente compreensível terá efeitos de rede. Desenvolvedores de terceiros adicionais vão olhar para a adoção bem-sucedida de um caso de uso e, em seguida, entrar, criar vários outros casos de uso. Então você vai ter um aumento na receita, novas oportunidades de negócios desenvolvidas, e seu negócio vai crescer muito mais. 24. Quem formam a equipe de API: Olá a todos. Nesta seção, vejamos a importância da equipe de API e de quem forma a equipe de API. Portanto, a equipe de API normalmente consiste no gerenciador de produtos da API, o arquiteto de API, desenvolvedores de API e evangelista da APA. Agora, em muitas organizações, elas podem não ser uma equipe dedicada de API, mas cada vez mais, as organizações estão entendendo a importância de ter uma equipe dedicada de API, ter a mentalidade do produto e criar APIs como produtos. Assim, os gerentes de produtos da APA são peça-chave desta equipe. Nas poucas palestras a seguir, você aprendeu que entende especificamente sobre as funções e responsabilidades de um gerente de produto de API, os arquitetos, desenvolvedores e a APA sem valor. Obrigado por ouvir e espero vê-lo na próxima aula. 25. Introdução às estratégias de preços da API: Agora vamos voltar para uma parte muito importante do gerenciamento de produtos de API, que é estratégias de preços da APA. Como você monetizar sua API? Em primeiro lugar, o que é monetização? Para simplificar, trata-se de ganhar dinheiro através da sua API. E a maneira como você ganha dinheiro, pode ser muito diferente. Pode ser que toda vez que alguém tem que usar sua API, precisa pagar você e, portanto, você ganha dinheiro. Então é uma receita diádica. Ou pode ser que cada vez que eles usam uma API e fazem uma compra de seu produto ou serviço, você realmente ganha dinheiro. Portanto, pode haver implicações de receita direta para a API. É um modelo de negócio. O outro poderia ser, você poderia oferecer uma API gratuitamente porque ela vai beneficiar indiretamente o seu negócio. Por exemplo, o Google e o Facebook podem oferecer uso de suas APIs porque eles obtêm mais dados de clientes, que não os ajudará diretamente a fornecer serviços mais personalizados aos clientes. Assim, da mesma forma, pode haver várias outras maneiras indiretas nas quais o uso da API pode afetar seus negócios. Então, essencialmente, é isso que a monetização está dizendo. Nas próximas seções, vamos discutir algumas das estratégias de preços populares para APIs. 26. Opções de preço de API: Quando se trata de estratégias de monetização para APIs são essencialmente quatro. Portanto, normalmente há quatro maneiras diferentes de as empresas prestarem APIs. Um é gratuito, não há preço para uso no trabalho da API. O próximo é o desenvolvedor paga pela API. O terceiro é que o desenvolvedor é pago por usar a API. E a última é oportunidades indiretas de negócios. 27. Aquarelas de economia de API: Portanto, antes de analisarmos as estratégias de preços específicas para uma API, vamos primeiro entender quem são as partes interessadas na economia da API. Então, primeiro, este é o provedor de API. Essencialmente, este é o negócio decidiu expor um monte de APIs para usuários de terceiros, e a parte interessada realmente determina o preço. E em seguida, os desenvolvedores de API que realmente consomem essa API e criam algo a partir dela e a oferecem a seus usuários finais. Então, finalmente, são realmente os usuários finais que se beneficiaram da API. Eles não necessariamente veem a API, mas são realmente os beneficiários reais da funcionalidade oferecida pela API. Para que sua estratégia de monetização seja realmente bem-sucedida, é importante que a API seja benéfica para as três partes interessadas diferentes. Então, qual é o preço que você determinou para a API não só deve ser benéfico para o seu negócio, mas também deve ser sustentável para o desenvolvedor de API para que ele possa fornecer um valor a esses usuários finais. Então, se você diz que sua API vai custar o valor X, mas o valor real que os desenvolvedores de terceiros realmente obter é menor do que o valor X que está realmente pagando você. Não é uma estratégia de monetização tão sustentável. Portanto, tenha em mente essas três partes interessadas diferentes quando você pensar sobre as várias opções de preços à sua frente para a sua API. 28. Precipitação da API livre: Agora vamos olhar para a primeira opção que é gratuita. Por que uma empresa ofereceria uma API gratuitamente? Então você ofereceria uma API gratuitamente por vários motivos. Um deles pode ser que você queira aumentar a adoção. Tão perto de crescer novo no mercado, não haveria ninguém que pudesse ver o valor na API o suficiente. Portanto, você pode querer provar o caso de uso para a API e, portanto, você oferece uma árvore inicialmente, ou você pode querer manter os consumidores que é maior concorrência. Então você quer oferecer serviços de API para que mais e mais parceiros que realmente fazer parceria com você em vez de concorrência. Ou pode ser que você está recebendo algo benefício dag. Por exemplo, logins sociais que estão disponíveis, como go, você pode fazer login através do Facebook, inscrever-se através do Google e assim por diante. Essas APIs são frequentemente oferecidas gratuitamente. Mas o benefício que essas empresas obtêm são mais dados de uso do cliente. O que isso beneficia os desenvolvedores terceirizados é porque oferece uma maneira muito fácil de identificar o usuário e simplificar o processo de login. Portanto, é uma vitória para todas as três partes dentro da economia de API. Portanto, há casos de uso legítimos para quando você pode considerar oferecer sua API gratuitamente. 29. Pays de desenvolvedor de preços de API: O próximo modelo de monetização é onde o desenvolvedor realmente paga pelo uso da API. Para que este modelo apenas sucesso desvalorização que o desenvolvedor recebe pelo uso da API deve realmente ser mais do que o APA está sendo realmente preço para. Isso é só então os desenvolvedores que realmente consideram pagar pela API. Há novamente, diferentes maneiras pelas quais você pode preço e API. Por exemplo, este pode ser um modelo pay as you go, pode ser um modelo freemium, pode ser um modelo hierárquico, ou um modelo baseado na taxa de transação. Então, quando você diz que o modelo pay as you-go é desenvolvido apenas paga para quando eles realmente usam a API. Então, toda vez que eles usam API que realmente colar na montagem, um bom exemplo para isso pode ser um aplicativo de verificação de crédito. Então, quando você pede um empréstimo para o banco, banco realmente faz uma chamada para a agência de verificação de crédito e eles pagam uma certa taxa para esse cheque de crédito específico. O outro poderia ser um modelo de negócios freemium, onde você oferece uma repentina um baixo valorizado funcionalidades API gratuitamente. Enquanto se eles querem funcionalidades premium reais são diferentes endpoints que são de maior valor. Eles terão que realmente pagar por essa API. Isso é semelhante à forma como as aplicações tradicionais oferecem modelos Freemium. Isso é para fazer com que as pessoas adotem sua API específica para acostumados a isso e gostam, e eles realmente ir para uma versão paga. O terceiro é um modelo hierárquico onde, onde você pode configurá-lo aqui dizendo que cada 10 mil acessos por dia, você realmente pode pagar isso. Se você usá-lo entre dez mil, quinze mil visitas por dia, você realmente terá um pago tanto. Ou, se você exceder os níveis que você realmente se inscreveu, você terá que pagar um valor realmente alto. Então, para que você possa rasgar o preço de uma forma. E os desenvolvedores poderiam realmente escolher o negócio que eles pensam que seria a sua taxa de uso real. Agora o último é um modelo baseado na taxa de transação. Onde você vai conseguir uma comissão para a transação? Paypal ou Stripe ou qualquer um dos aplicativos de pagamentos. Um bom exemplo. Então, cada vez que você acerta uma API de pagamentos e fez uma transação e você recebe uma certa porcentagem de taxa para a transação. Então, estes são os diferentes modelos em que você pode avaliar a API. E elas não são as únicas maneiras que você pode realmente avaliá-las, mas essas são algumas das maneiras populares. 30. Prejuízo de API Pricing Developer: O próximo modelo de monetização é onde o desenvolvedor é pago pelo uso da API. Portanto, este modelo pode ser usado onde você como o provedor de API são realmente beneficiados mais pela API está sendo usado por desenvolvedor de terceiros. Então você precisa incentivar os desenvolvedores a usar a API e, portanto, você paga a API. Assim, alguns exemplos para isso são agregadores de viagens de agregadores de voos ou agregadores de hotéis são realmente beneficiar deste modelo de preços. Por exemplo, cada vez que uma venda é feita através da API específica é um hotel operá-los e realmente fornecer uma comissão. Desenvolvedores porque eles estão essencialmente agindo como agentes dirigindo mais vendas para o meu hotel. Então, outro modelo popular é o modelo de referência ou afiliado. Você pode estar ciente de que pode ser um usuário afiliado da Amazon pode impulsionar compras de produtos na Amazon, você recebe uma taxa para cada referência. Da mesma forma, se houver mais tráfego ou mais compras feitas em seu site através de sites afiliados, você pode incentivar os desenvolvedores pagando-os. Alguns dos exemplos populares são, você sabe, Google e Google AdWords, companhias de seguros e agentes, ou em sites de emprego como Monster.com e assim por diante.