Bem-vindos a mais um episódio do Microsoft Knowledge Nugget. Eu sou seu apresentador, Mirko Pito. O tópico de hoje é algo que quase todo mundo já ouviu falar, mas poucos entendem de verdade. APIs. Você provavelmente ouve esse termo sendo usado por aí. É uma daquelas palavras da tecnologia que as pessoas usam para parecer que sabem do que estão falando. Mas aqui está o ponto. APIs são, na verdade, simples. Elas são apenas uma forma de um software conversar com o outro. Seu celular solicita dados a um servidor. Servidores envia de volta. Isso é uma chamada API. Agora, imagine que você tenha 20 APIs, ou 50, ou 100. Cada uma pode usar uma autenticação diferente. Limites de taxa distintos e documentações variadas testes. É que existe. De repente, o que começou como uma conversa simples entre dois aplicativos vira um caos completo. Sem um gerenciador central, cada equipe acaba reinventando a roda.

Uma equipe cria seu próprio sistema de autenticação. Outra cria seu próprio sistema de logs. Brechas de segurança aparecem por toda parte. Desenvolvedores ficam confusos sobre o que cada API faz. E você não tem uma visão única do que está acontecendo em todo o seu sistema. O Azure API Management resolve isso. Prefere ser você uma central de controle. Pense nele como uma torre de controle de tráfego aéreo para suas APIs. Ao final deste episódio, você entenderá o que ele realmente é. Por que é importante e como todas as peças se encaixam. Pegue seu café e vamos mergulhar no assunto. Problema, muitas APIs, nenhum controle. Aqui está a realidade do software moderno. Dez anos atrás, você provavelmente tinha um grande aplicativo, um monólito. Um banco de dados, uma API. Era simples. Hoje, esse mesmo aplicativo pode estar dividido em dezenas de microserviços. Cada serviço cuida de uma coisa. Contas de usuário, pagamentos, estoque, notificações.

E cada um expõe sua própria API. De repente, você tem 10, 50, 100 pontos de entrada diferentes no seu sistema. Agora, imagine que você é um desenvolvedor tentando criar algo que usa essas APIs. Você precisa encontrar cada um e descobrir a autenticação para todas elas. Algumas usam chaves de API, outras usam o Alt, algumas não usam nada. Você precisa gerenciar o limite de taxa manualmente e ocorre o risco de ser bloqueado. Você precisa entender o formato de dados que cada um espera. É exaustivo. E fica pior do ponto de vista operacional. Sem um gateway central, cada equipe precisa adicionar segurança e logs manualmente ao seu próprio serviço. Algumas equipes fazem bem, outras esquecem de registrar erros. Algumas nem validam os dados de entrada. Inconsistente e sujeito a erros. Um pesadelo de segurança prestes a acontecer. A conformidade torna-se quase impossível. Você provar quem acessou o que e quando.

Boa sorte tentando extrair trilhas de auditoria de 20 serviços diferentes, cada um com seu próprio formato de log. Precisa ver quantas chamadas de API seu sistema processou no mês passado. Você acaba compilando métricas de uma dúzia de painéis diferentes. O problema é o seguinte. À medida que você escala, isso não apenas atrapalha. Isso o quê? Você não pode adicionar mais desenvolvedores, serviços ou clientes sem um ponto central de controle. Pense nisso como um prédio. Imagine que cada sala tem uma fechadura diferente. Não há recepção ou diretório. Os visitantes vagam tentando encontrar a porta certa, ficam frustrados e acabam desistindo. Caos total. Esse é o problema que o gerenciamento de API foi projetado para resolver. O que é o Azure API Management? Atoio de controle. Então o que exatamente é o Azure API Management? Aqui está a definição mais simples. É um serviço gerenciado que fica entre suas APIs de back-end e os aplicativos, sites, dispositivos e parceiros que as consomem.

Mas veja bem, não é apenas um proxy. Um proxy é apenas em caminho ao tráfego. O Azure API Management cobre todo o ciclo de vida das suas APIs. Publica e proteja, monitore e eventualmente desative-as. É um centro de controle completo. Vamos dividir em três componentes principais. Primeiro é o gateway. Esta é a porta de entrar. Cada solicitação vinda de um aplicativo ou site chega primeiro ao gateway, nunca diretamente ao seu back-end. O gateway processa a solicitação, aplica as políticas que você configurou, ou coleta métricas e as encaminha para o serviço de back-end correto. Pense nele como um guarda de trânsito. O próximo é o plano de gerenciamento. É aqui que você define tudo. Suas APIs, suas políticas, seus produtos, suas assinaturas. Você faz isso pelo portal do Azure, pela linha de comando, ou por infraestrutura como código, como Bicep ou Terraform. É a sala de controle onde você configura como tudo funciona.

Então o portal do desenvolvedor. Este é um site de autoatendimento, onde desenvolvedores, internos ou externos, podem descobrir suas APIs, ler documentação, obter chaves de assinatura e até testar chamadas de API direto no navegador. Chega de enviar PDFs por e-mail para lá e para cá, que vai uma analogia que ajuda. Pense em um aeroporto moderno. Gateway é a pista de pouso. Todo avião pousa lá primeiro. O plano de gerenciamento é ator e controle. Ele direciona o tráfego, estabelece regras e monitora tudo. E o portal do desenvolvedor é o painel de informações. Antipilotos o consultam antes de voar e encontram todas as informações necessárias sem precisar falar com ninguém. Agora, vamos focar no Gateway. Essa é a parte com a qual seus aplicativos realmente interagem e onde a mágica acontece. Gateway, a porta de entrada da sua API. Vamos falar sobre o Gateway, porque essa é a parte com a qual seus aplicativos realmente interagem.

Toda solicitação de um aplicativo móvel, site ou dispositivo, eu atinge o Gateway primeiro. Nunca seu back-end diretamente. Esse é o ponto principal. O Gateway fica na frente e atua como um ponto de entrada único. O Gateway pode aplicar políticas antes de encaminhar a solicitação. Políticas são regras que você escreve em XML ou JSON como limite de taxa, filtragem de IP, reescrita de cabeçalho e verificações de autenticação. Tudo isso não se alterar uma única linha do código do seu back-end. Este é um exemplo concreto. Digamos que você tenha um nível gratuito e um nível premium para a sua API. Com a política, você pode limitar usuários gratuitos a 5 solicitações por minuto, enquanto usuários premium recebem 100. Seu back-end nunca percebe a diferença. Ele apenas processa ações. O Gateway cuida da execução. O Gateway também cuida do cache. Se dados são solicitados repetidamente com uma lista de produtos que raramente mudam, o Gateway pode armazenar resposta e servi-la diretamente.

Não há necessidade de incomodar seu back-end, o que significa respostas mais rápidas e menos carga em seus servidores. Ele também pode transformar dados. Seu back-end pode retornar a XML, mas seu aplicativo móvel espera JSON. Gateway pode converter isso instantaneamente. Seu back-end não precisa mudar e seu aplicativo também não precisa, o Gateway cuida da tradução. E ele registra cada chamada, cada solicitação, cada resposta, cada erro. Você obtém um rastro de auditoria completo de quem chamou o que, quando e o que aconteceu. Só isso já vale o investimento para fins de conformidade. Se você tem um público global, pode implantar o Gateway em várias regiões. O tráfego é roteado automaticamente para mais próximo, o que proporciona menor latência e melhor. Mais uma coisa, o Gateway oculta o URL real do seu back-end. Os clientes veem apenas o Gateway. Seus servidores de back-end permanecem ocultos da internet.

Isso é uma grande vitória de segurança para uso. Políticas, o motor que controla tudo. Então, e sobre essas políticas que menciono? Elas são o motor que tornam o API verdadeiramente poderoso. Uma política modifica o comportamento de solicitação ou resposta sem você nunca tocar no código do seu back-end. Pense nisso como um invólucro em torno da sua API. À medida que o tráfego flui, ele pode adicionar, remover ou alterar coisas automaticamente. Políticas podem ser executadas em quatro pontos do ciclo de vida da solicitação. Inbound. Na entrada, antes da solicitação chegar ao seu back-end. Outbound. Na saída, antes da resposta chegar ao cliente. Back-end, logo antes da solicitação atingir seu serviço. E em caso de erro, quando algo falha. Entradas comuns incluem validar tokens JWT para verificar a identidade do chamador. Conferir chaves de API, reescrever o URL e se restringir por endereço IP.

Tudo isso acontece antes que o seu back-end veja uma única requisição. Para saídas, você pode transformar o corpo da resposta. Localizar e substituir texto. Remover campos sensíveis e alterar formatos. Você pode armazenar respostas em cache para que solicitações repetidas não atinjam seu back-end. Você pode até remover cabeçalhos que vazem informações inteiras. Aqui está um exemplo concreto. Digamos que sua API retorne em descrições de produtos com a palavra azul por toda parte. Quer mudar a marca ou usar amarelo em vez disso? Em vez de alterar seu código de back-end, você adiciona uma política de saída. Localizar azul, substituir por amarelo e pronto. Seu back-end nunca muda. Políticas de limitação de taxa e cota protegem seu back-end contra abuso. Se o aplicativo de alguém agir de forma descontrolada e começar a martelar sua API 10 mil vezes por segundo, a política entra em ação e diz devagar.

Seu back-end permanece saudável. Isso é de lógica avançada. Você pode escrever expressões se acharem que é personalizadas dentro das políticas. Elas são compiladas para desempenho. Tanto não há custo de tempo de execução. Você pode consolidar funções de usuário, calcular limites de taxa dinâmicos, ou transformar respostas condicionalmente com base nos cabeçalhos da solicitação. A principal conclusão é esta. As políticas permitem que você controle como suas APIs se comportam sem tocar no código que as executa. Isso significa mudanças mais rápidas, menos implantações e menos risco. Produtos e assinaturas. Empacotando APIs para consumidores. Agora suas APIs estão definidas, as políticas estão em vigor e o Gateway está funcionando perfeitamente. Mas como você dá a clientes diferentes acesso a coisas diferentes? É aí que nos produtos e as assinaturas. No Appim você agrupa APIs em algo chamado produto.

Pense nisso com um pacote. Você pode ter um produto de nível gratuito que inclui apenas suas APIs básicas. Talvez apenas acesso de leitura, depois um produto premium que inclui tudo, incluindo operações de escrita e endpoints de administração. Os desenvolvedores não assinam APIs individuais, eles assinam um produto. Quando eles assinam, recebem uma chave de assinatura. Na verdade, duas chaves, para que você possa rotacionar uma sem tempo de inatividade. Essa chave é o passe deles para usar qualquer API naquele produto. Você controla como as assinaturas funcionam. Os produtos podem exigir aprovação. Você aceita manualmente cada assinante, ou eles podem ser abertos para alto atendimento. Qualquer pessoa se inscreve e obtém acesso imediato. Você também pode incluir termos legais que os usuários devem aceitar antes de assinar. Isso é importante se suas APIs lidam com dados sensíveis. É assim que você monetiza APIs.

Um produto gratuito com limites de taxa abaixo, 5 chamadas por minuto. Um produto pago com limites maiores ou mais endpoints. 100 chamadas por minuto, além de acesso a recursos premium. Sabe o que importa? O Gateway impõe os limites com base no produto ao qual o chamador se inscreveu. E aqui está um exemplo real. Imagine que você está criando um aplicativo de conferência. Você cria um produto para participantes com APIs para a programação das sessões, biografias dos palestrantes e mapa do local. Depois, um produto para patrocinadores que também inclui APIs de geração de leitos. E os patrocinadores podem escanear os crachados dos participantes e obter informações de contato. Mesmo back-end, produtos diferentes, níveis de acesso diferentes. Essas duas chaves de assinatura são projetadas para a rotação. Se uma chave for comprometida, você gera uma nova. A segunda chave permite que você faça a troca sem interromper o serviço.

Gere uma nova chave, atualize seu aplicativo e revogue a antiga. Sem interrupção. Portal do desenvolvedor. Autoatendimento para consumidores de AP. Então você configura os seus produtos de AP. Agora os desenvolvedores precisam de mim. Esse é o trabalho do Portal do Desenvolvedor. O Portal do Desenvolvedor é um site integrado a cada instância de APIN. Os desenvolvedores o usam para navegar pelas suas APIs, ler a documentação e testar endpoints interativamente direto no navegador. Sem necessidade de configuração e sem troca de meios. Mas um detalhe, ele não é publicado por padrão. Ao criar sua instância de APIN, o Portal existe, mas ninguém pode vê-lo. Você precisa personalizá-lo e publicá-lo primeiro. Isso é intencional. Você não quer mostrar um portal inacabado para o mundo. Você pode personalizar cores da marca, logotipos e até incorporar conteúdo do WordPress para um blog junto às suas documentações de APIN.

Ele é totalmente personalizável para combinar com a identidade visual da sua empresa. O valor real é o autoatendimento. Os desenvolvedores se cadastram, obtêm suas chaves de assinatura automaticamente e começam a chamar as APIs imediatamente. Sem e-mails manuais, sem espera por aprovação, sem tiques de suporte perguntando como obter uma chave. Eles fazem tudo sozinhos, o que reduz significativamente sua cara de suporte. Você também pode publicar logs de alterações de versão. Quando você atualiza uma API, os desenvolvedores vêm no Portal sem surpresas. O acesso pode ser público para qualquer pessoa com a URL. Ou você pode restringi-lo a usuários do seu tenant do EntraID para que apenas pessoas da sua organização naveguem. Ambas as opções existem para diferentes casos de uso. O Portal do Desenvolvedor é o que torna o seu gerenciamento de IP em uma plataforma real. Pense nele com uma vitrine para suas APIs.

Sem ele, os desenvolvedores precisam procurar em documentos e perguntar por aí. Com ele, eles encontram o que precisam e começam a desenvolver. Segurança, autenticação, autorização e segredos. Todo esse poder é inútil se a segurança não estiver garantida. Então, vamos falar sobre como o API lida com identidade, acessos e segredos. O API suporta múltiplos métodos de autenticação. Mais simples são as chaves de assinatura sobre as quais falamos anterior. Mas, para sistemas em produção, você deseja algo mais forte, como o OAuth 2.0, o token JWT, certificados de cliente ou filtragem de IP. Você cria camadas com base no nível de sensibilidade da sua API. Para a produção, a melhor prática é usar o OAuth 2.0 com o EntraID. Veja como isso funciona. O aplicativo cliente obtém um token do EntraID e o envia na solicitação da API. O APIN valida o token verificando a assinatura, o emissor, o público e a expiração.

Se for válido, o APIN encaminha a solicitação para seu back-end, incluindo o token. Seu back-end confia nele, porque o APIN já o verificou, então não precisa revalidar. Isso é menos uma coisa para cada serviço lidar. Agora, vamos falar sobre segredos. Chaves de API, strings de conexão, certificados. Você não quer isso codificado em arquivos de política ou controle de origem. O APIN possui um recurso chamado valores nomeados. E você armazena segredos centralmente no APIN e os referencia pelo nome em suas políticas. O valor real nunca aparece no código da sua política. Melhor ainda, você pode conectar valores nomeados ao Azure Key Vault. E os segredos permanecem criptografados no Key Vault e o APIN os busca em tempo de execução. Ninguém, nem mesmo sua equipe de DevOps vê o valor real do segredo. Quando precisar rotacionar uma chave, atualize no Key Vault e o APIN detecta mudança automaticamente.

O APIN também oferece suporte à identidade gerenciada. Isso permite que o APIN autentique em outros serviços do Azure, como Key Vault, ou uma Key Vault, ou uma Page Backend, sem armazenar credenciais. O Azure gerencia a identidade, então você apenas concede as permissões. E para isolamento de rede, você pode implantar o APIN dentro de uma rede virtual. Esse é o nível premium. Ou, coloque o Azure Front Door. O ponto é que seus serviços de back-end nunca precisam ser expostos diretamente à internet. O APIN é a única coisa que o mundo exterior vê. Essa abordagem em camadas constrói uma defesa em profundidade. Autenticação no Gateway, segredos em um cofre, isolamento de rede em torno dos seus back-ends. Cada camada fortalece a próxima. Níveis de preço, qual se encaixa melhor para você? Então, quanto custa? Vamos percorrer os níveis. Nível de consumo. Pague por chamada de API sem custo mensal fixo.

Perfeito para baixo volume ou cargas de trabalho variáveis, como quando você está apenas prototipado. Você ainda não tem certeza do que precisa, comece por aqui. O nível de desenvolvedor oferece um custo mensal fixo baixo em torno de 50 dólares. Conjunto completo de recursos, uma SLA. Ideal para ambientes de desenvolvimento dele. Você tem tudo o que o premium oferece, mas não pode usar em produção. Nível básico ou nível de entrada para produção? Menor rendimento, sem suporte à rede virtual, mas você obtém um SLA real. Bom, para ferramentas internas ou pequenos projetos, onde rede privada não é crítica. A maioria das empresas escolhe o nível estando. Inclui suporte à rede virtual, SLA de 99,95% e bom throughput. Se você executa APIs essenciais ao negócio, é aqui que provavelmente ficará. O nível premium é para empresas globais que precisam de máxima confiabilidade e rede privada. Implantação multiregional, gateway auto-hospedado, SLA de 99,99% virtual e gestão total em rede virtual.

Começa em torno de 2.700 por mês por unidade. A Microsoft também introduziu os níveis V2, Basic V2, Standard V2 e Premium V2. Eles simplificam a precificação com cotas de requisição inclusas e cobrança branding. Em vez de monitorar vários medidores, você tem um volume claro de requisições e paga pelo uso extra em incrementos simples. Veja como escolher. Comece com o developer para testes. Mude para o Standard para a produção. Vá para o Premium se precisar de escala global ou rede privada. E lembre-se, você sempre pode migrar de nível mais tarde. Comece pequeno e cresça conforme suas necessidades. Aqui cobrimos. O gerenciamento de API organiza o caos de muitas APIs em uma central de controle para gateway política, segurança e experiência do desenvolvedor. O ponto principal é que ele é mais do que um proxy. Pense nele como o cérebro e o sistema nervoso do seu ecossistema de APIs. Sem ele, cada equipe cria a sua própria autenticação, logo em limite de taxa.

Você acaba com inconsistência, falhas de segurança e nenhuma visão única do que está acontecendo. Com ele, você obtém consistência, segurança e escalabilidade, sem reinventar a roda, para cada serviço, alas. Questão, exercício simples. Pense em uma API que você expõe diretamente no momento. Talvez um endpoint de função ou um serviço de aplicativo. Como colocar o gerenciamento de API na frente mudaria sua postura de segurança e sua capacidade de monitorar o uso. Só de pensar nesse exercício, você já verá o valor. Próximo passo, inscreva-se no canal. Em episódios futuros, mostraremos como importar uma API, aplicar sua primeira política e monitorar o uso em tempo real. Você passará da teoria para a prática. E se você achou útil, compartilhe com alguém que esteja criando um aplicativo. Isso economizará meses de dor de cabeça para ele. Obrigado por assistir.