Resultados da busca

Você já se perguntou como a Inteligência Artificial (IA) pode contribuir para a estratégia de microsserviços? Neste post vamos explorar as possibilidades. Confira! A IA pode ajudar a resolver alguns dos problemas mais difíceis que os microsserviços enfrentam hoje. Abaixo estão algumas conquistas que já estamos vendo a IA alcançar: Previsão de Carga: Entender a carga do sistema e agir sobre ela antes que aconteça, permitirá que os sistemas providenciem mais recursos antes que sejam necessários. A provisão de recursos não se limita apenas à rede e ao número de tarefas em execução; a IA pode acionar antecipadamente recursos ao negócio como profissionais para o atendimento ao cliente, aumento de infraestrutura e quando e somente quando necessário. O Algoritmo de Regressão Linear é o mais usado para esses casos pois estima o comportamento futuro de uma variável com base em seus dados passados. Detecção de Anomalias: A detecção de anomalias já está incorporada em muitos serviços de monitoramento e é eficiente na detecção de picos, cargas e comportamentos anormais; no entanto, detectar um decaimento de serviço, mesmo gradativo ou sutil, é difícil. A IA pode ajudar os sistemas a reconhecer se os serviços estão reagindo de forma diferente ao longo do tempo e quais são as razões para esse decaimento. Também tem o potencial de ser mais eficaz na identificação de bugs com base no estudo de clusters de microserviços que apresentam problemas contínuos. O Algoritmo de Detecção de Anomalias é o mais usado para detectar padrões incomuns ou anômalos em dados. Planejamento de Recursos: À medida que a escala e a complexidade dos microserviços crescem, também cresce o uso da nuvem. A capacidade de planejar com antecedência usando uma gestão inteligente de recursos pode salvar custos significativos, mantendo ao mesmo tempo um serviço estável e robusto. Algoritmo de Otimização de Recursos é o mais usado para ajudar a encontrar a melhor solução possível para um problema de otimização de recursos, com base nos dados de uso. Segurança: A segurança já está usando a IA em muitos lugares, descobrindo padrões de ataques com base em comportamentos conhecidos. Aproveitando essas capacidades no nível da rede e do banco de dados, pode-se melhorar a segurança para as ações realizadas por uma pessoa autorizada. Se você conseguir entender os padrões de uso e agir sobre eles, pode definir um sistema mais seguro para todos os usuários. O Algoritmo de Classificação é o mais usado neste caso e serve para classificar dados em categorias específicas. Este pode ajudar a identificar padrões de uso e ações de usuários autorizados e ações maliciosas. Esta informação pode ser usada para melhorar a segurança do sistema. Quer saber mais como aplicamos IA no desenvolvimento de microserviços?! Entre em contado! Contato: https://www.seedts.com/contato

As equipes de segurança estão enfrentando um problema cada vez mais comum à medida que a prevalência de APIs cresce - a implantação geralmente supera os processos e proteções de segurança, criando uma vulnerabilidade que precisa ser abordada. Como as APIs se tornam o próximo grande vetor de ataque, é essencial entender o equilíbrio entre proteger as APIs e o custo potencial de não agir. Para obter adesão organizacional, é importante criar um plano em fases que forneça maior visibilidade das APIs, determine quais APIs expõem dados confidenciais e estabeleça processos para gerenciar APIs. Estratégias para proteger APIs sem comprometer a velocidade de desenvolvimento são super essenciais. Um dos segredos é inserir na Governança de Arquitetura políticas de segurança que irão guiar desenvolvedores de novas APIs. Tais políticas são aplicadas de acordo com a categoria das APIs. Algumas técnicas de segurança podem ser consideradas mínimas e, portanto, nenhuma API deve ser publicada em produção sem sua implementação, dentro destas categorias estão OAuth, OpenID Connect e Quotas. Políticas de segurança mais rebuscadas, como quando a sua empresa precisa ter APIs PCI compliance, requerem mais atenção a segurança e mais fáceis de implantar quando você utiliza um gerenciador de APIs consistente, como o Apigee, são: Security Headers, Validação de Entrada (JSON Protection, XML Protection, Regular Expression Protection), entre outras. Também é importante que seu Backend esteja integrado, em termos de segurança, com suas APIs e Gerenciador de APIs. Logo, possuir segregação de domínios com Service Mesh (ex.: Istio, Consul) atrelado a um IAM (ex.: Keycloak) e Gestão de Segredos (ex.: Vault) é uma ótima prática. Por fim, para saber como anda realmente a sua Governança de Arquitetura com suas políticas de segurança implantadas em ambiente de execução, tenha um SIEM (ex.: Apache Metron) com seus coletores de dados (ex.: Apache Nifi) vão lhe ajudar a ter a visão do que está ocorrendo em relação a segurança como um todo, inclusive das APIs. Ah! Sobre IASec falamos depois. Para saber mais como proteger suas APIs. Follow the link! Link: https://www.seedts.com/estrategia-de-apis

Você precisa melhorar a arquitetura de dados para sua empresa, mas não sabe por onde começar? Desenvolver uma arquitetura de dados é um passo crítico para melhorar seu negócio. Neste item com a revolução do Data Mesh, o DDD tem um papel fundamental. Com domínios definidos, os dados são do domínio, sua inteligência (IA) também, assim como desenvolvedores, documentos, relatórios, bibliotecas, data sets, etc. Quando um domínio precisa de dados de outro domínio, essa relação fica bem clara: Quem é o dono do dado, seu contexto, a abordagem de ver o dado como Produto e a disponibilização do mesmo para o mundo externo (outro domínio). Em resumo, com Data Mesh, os dados são armazenados em domínios, segregados, com donos que o encaram como Produto e onde a IA atua consegue tomar melhores decisões com base em informações precisas sobre os dados de(os) domínio(s). Entre em contato com a SeedTS para começar a desenvolver uma arquitetura de dados que irá melhorar seu negócio.

Postado originalmente em Mundo API: https://mundoapi.com.br/materias/api-first-e-mocks/ Hoje não é mais uma tendência a estratégia de desenvolvimento com API First, este é o modelo atual. Se falarmos de tendência na linha de construção de sistemas podemos falar em AI First, não API First. Vamos nos focar aqui no API First e principalmente em seu Mock dentro de uma estratégia de desenvolvimento. A abordagem do API First, na qual a construção da API é feita primeiro, prega que sistemas se preocupem primeiro com seus consumidores e como a informação será ofertada a estes, vinda do Backend. Desta forma a mesma informação poderá ser apresentada ou usada de acordo com a aplicação chamadora (chamada de Consumidores de APIs). Mocks de Valor Agora imagine que você deseje lançar o seu App asap e o seu usuário (cliente final) quer ver como será a usabilidade, navegabilidade, gráficos de todos os formatos e tipos, dados a serem apresentados em tela com o intuito de ver “se é isso” que se deseja na forma mais próxima da real, quando o App entrar em produção. Detalhe: Tal App Consumidor de APIs, pode ser um sistema feito sob IOS, Android, Web, IoT, entre outros. Nestes, o dado recebido pode ser o mesmo, a apresentação ou consumo, não. As vezes nem é seu usuário que possui tal necessidade, e sim o seu gestor que deseja economiza no desenvolvimento ou mesmo evitar atritos, visto que muitos retrabalhos poderiam ser evitados se o entendimento dos requisitos de apresentação das informações do Backend fosse o mais próximo do que o usuário final deseja ver ou consumir. Também imagine que você deseje fazer paralelismo de desenvolvimento entre Backend e Frontend de forma independente. Neste caso, após o contrato e documentação da API serem definidos (API Proxy e Swagger) – abordagem API First- ambos aos times vão para suas posições para desenvolver de acordo com suas especialidades, pois foi acordado com um irá se comunicar com o outro. Todos esses cenários acima nos levam a uma estratégia de desenvolvimento simples, mas importante: API First + Mocks. API Mocks Após a definição de sua API com a estratégia de API First os Mocks são construídos, repare na figura abaixo. Em Azul temos a API Proxy definida com abordagem API First, onde e está é efetivamente a API que será consumida pelo Consumidores de APIs. Em verde está a API Proxy “mockada” que busca simular o backend,se este não estiver construído ou mesmo instável (já tive situações assim). Tal mock fornece todas as informações (UM na figura) que a seu App precisar. Já quando o seu microsserviços estiver pronto ou legado disponível, estes poderão responder à API Proxy (Dois na figura abaixo) diretamente que você criou com a estratégia de API First. Aí sua API Mock sai de cena. Em resumo a abordagem de Mock para APIs Proxies em um processo de desenvolvimento serve para: Aproximar o usuário final do que será a aplicação, antes de se desenvolver o backend; Dar liberdade a times distintos, seja Backend e Frontend; Criar velocidade de entrega para a aplicação como um todo; Validar a própria API no contexto de seus consumidores; Economizar $$$ evitando retrabalhos, visto que o usuário final poderá mudar de “ideia” (requisitos na camada consumidora da API) antes mesmo de se construir o backend. Bem, agora você sabe que Mocks de APIs são super importantes em uma esteira de desenvolvimento, bora por em prática! Inté, #API #Mocks

Postado originalmente em Mundo API: https://mundoapi.com.br/apis-publicadas/8-alternativas-poderosas-para-a-api-do-google-maps/ O Google Maps é um dos favoritos por seus serviços de geolocalização em todo o mundo. Seu amplo banco de dados de recursos geográficos, pequenas empresas e imagens de rua em todo o mundo é difícil de superar – e é por isso que a API do Google Maps há anos é a melhor opção para desenvolvedores. No entanto, em julho de 2018, o Google aumentou drasticamente as taxas de sua API de mapas. Anteriormente, você podia criar até 25.000 exibições gratuitas de mapas por dia, com uma cobrança de US$ 0,50 por cada 1.000 subsequentes. A partir de 16 de julho, você terá até 28.000 exibições gratuitas de mapas por mês, com a cobrança de cada 1.000 subsequentes no valor de US$ 7,00 (um aumento de 14 vezes no preço!) Essas 28.000 visitas gratuitas, a propósito, representam os US$ 200 mensais que os desenvolvedores de crédito recebem atualmente para gastar em sua escolha de solicitações de Mapas, Rotas e Lugares. Assim que tudo estiver esgotado, o Google usará como padrão o carregamento de seu cartão de crédito para chamadas adicionais, a menos que você defina um limite diário para seu aplicativo, o que significa que os usuários verão uma tela em branco maravilhosa. A API do Google Maps é muito cara, e agora? Listamos 8 alternativas da API do Google Maps Para a grande maioria dos pequenos desenvolvedores, essa alteração nos preços faz com que a API do Google Maps seja a mais acessível. Então, e agora, você desiste, nega o serviço de usuários ou começa a desenhar seus próprios mapas? Achamos que temos uma opção melhor – na verdade, precisamente cinco opções melhores – para sua correção diária de dados de geolocalização: 1. OPENLAYERS OpenLayers é uma solução totalmente gratuita para exibir mapas dinâmicos em uma página da Web ou aplicativo. Ele desenha peças de uma variedade de fontes, incluindo o OpenStreetMap , cuja API é boa apenas para geodados brutos. Além dos mapas básicos, o OpenLayers também permite renderizar camadas vetoriais em seu mapa e soltar marcadores onde você quiser. Nada mal para um serviço totalmente gratuito! Preço: Gratuito Recursos: mapas lado a lado, mapas vetoriais, marcadores 2. TOMTOM Nossa próxima solução de mapeamento é a TomTom, e você pode apostar que seus mapas são muito bons, dada sua reputação de navegação por satélite. Embora este serviço seja pago, eles fornecem até 2.500 transações gratuitas por dia – ou 75.000 por mês, em comparação com os 28.000 do Google. De fato, eles oferecem significativamente mais funcionalidade. Além de exibir mapas, você também pode procurar locais, ver a densidade de tráfego e encontrar as melhores rotas de A até B. Preço: Grátis por 2.500 solicitações diárias, US$ 0,42– US$ 0,50 por cada 1.000 subsequentes (por descontos para pedidos maiores) Características: mapas lado a lado, mapas vetoriais, marcadores, pesquisa de localização, densidade de tráfego, localização de rotas 3. MAPBOX O Mapbox é a escolha do Facebook e do Snapchat para as necessidades de mapeamento. Desenhando dados de fontes abertas e proprietárias, o Mapbox oferece mapas, pesquisas de localização, navegações e recursos de mapas personalizados. São estes mapas personalizados que tornam o Mapbox extremamente popular, uma vez que é algo que poucos concorrentes oferecem. Em termos de preços, o Mapbox fica entre a TomTom e o Google Maps. Você pode receber até 50.000 solicitações gratuitas por mês, após o que é meio dólar por mil a mais. Preço: Grátis para 50.000 solicitações diárias, US$ 0.50 para cada 1.000.000 Recursos: mapas lado a lado, mapas vetoriais, marcadores, pesquisa de localização, localização de rotas, mapas personalizados 4. HERE A Counterpoint Research diz que “HERE é o líder indiscutível no ecossistema de localização”, e a qualidade de suas ferramentas de mapeamento realmente corresponde a essa expectativa. Sua cobertura abrangente tem uma precisão impressionante e é atualizada quase diariamente. Além de todos os recursos oferecidos por outros provedores, o HERE oferece uma ampla funcionalidade de visualização de mapas, além de dados de transporte público e muito mais. Seu modelo de precificação difere um pouco das nossas outras sugestões, portanto, dê uma olhada abaixo para ver se é melhor para você. Preço: gratuito para 250.000 solicitações por mês, US$ 1 para cada 1.000 ou 449 dólares por 1.000.000 solicitações mensais Recursos: mapas lado a lado, mapas vetoriais, marcadores, pesquisa de localização, localização de rotas, mapas personalizados, visualizações de mapas, transporte público 5. MAPFIT Mapfit é nossa próxima escolha para uma API de mapeamento. Ao contrário das outras opções nesta lista, o Mapfit tem um objetivo muito particular: criar mapas ultra precisos, até a entrada. Enquanto eles não oferecem muito mais do que mapas e direções, é difícil reclamar quando portas, docas de carga e garagens são contabilizadas! Eles oferecem algumas opções de preços flexíveis: Preço: Gratuito para 50.000 solicitações não comerciais mensais (Comunidade) OU US$ 49 para 250.000 solicitações mensais, US$ 0,50 para cada 1.000 (crescimento) OU US$ 1.449 por 5.000.000 solicitações mensais, US$ 0,20 para cada 1.000 (Escala) subsequente Recursos: Mapas lado a lado, mapas vetoriais, marcadores, busca de localização, localização de rota, características de construção (por exemplo, portas) 6. MICROSOFT A Microsoft oferece vários programas de Licenciamento por Volume, cada um adaptado às necessidades de diferentes tamanhos de empresas e tipos de organizações. 1. Preço: O Bing Maps está disponível através dos seguintes programas: Valor Aberto Subscrição com Valor Aberto Atrelado a produtos e serviços da Microsoft já contratados Contrato Empresarial Contrato “Select Plus” Programas baseados em assinatura oferecendo nível de entrada em 100 mil transações por mês por US$ 4.500,00 2. Recursos: Mapas para aplicações Web e Mobile, Mapas para usuários Windows 10 (Smartphones, PCs, tablets), Mapas para WPF, REST, Spatial, Serviços de Gerenciamento de Frota. 7. MAPQUEST O MapQuest oferece uma boa seleção de produtos de mapeamento digital, incluindo o site MapQuest.com, MapQuest Mobile, MapQuest Local, MapQuest Enterprise e MapQuest Developers. Preço: Começa com o plano grátis para 15.000 transações mês e plano básico em US$ 99,00 até planos corporativos. Recursos: Existem duas versões da plataforma MapQuest: Dados Licenciados e Abertos. A plataforma de Dados Licenciados está disponível com uma licença do MapQuest Enterprise Edition, e a plataforma Open Data está disponível com uma licença Livre e Aberta. Deve-se notar que o OpenStreetMap é a principal fonte de dados para o MapQuest Open Data Platform. O MapQuest Track possui um site ao desenvolvedor que tem uma documentação bem projetada, um construtor de mapas, um assistente de mapa estático, um planejador de rotas e outras ferramentas de desenvolvedor. Além disso, o MapQuest fornece uma API JavaScript do Google Maps, um conjunto de Open Web Services. 8. CARTODB O CartoDB é um mecanismo de mapeamento, análise e visualização de código aberto que permite aos desenvolvedores criar aplicativos geoespaciais móveis e da Web. O CartoDB foi lançado em abril de 2012 e desde então ganhou vários usuários de alto perfil, incluindo a National Geographic, a NASA, o The Guardian UK e o Twitter. Preço: O CartoDB oferece vários planos que variam de um plano básico gratuito a um plano corporativo repleto de recursos. Também possui planos grátis para estudantes. Recursos: O CartoDB fornece uma biblioteca JavaScript (CartoDB.js) e várias APIs que os desenvolvedores podem usar para adicionar mapas envolventes e visualizações geoespaciais a seus aplicativos. O CartoDB também fornece um editor com uma interface intuitiva de arrastar e soltar que permite aos usuários criar mapas rapidamente e visualizar dados. A documentação da plataforma e do editor do CartoDB é bem organizada e fácil de seguir. RESUMO É isso para nossas cinco principais alternativas à API do Google Maps. Há muito mais opções por aí ( aqui estão mais algumas daquelas comparadas), mas cada uma dessas cinco opções brilha à sua maneira. Precisa de ajuda para decidir qual usar? Aqui está nossa rubrica instantânea para fazer isso: Se você precisar de navegação , escolha TomTom Se você precisar de precisão, escolha Mapfit Se você precisar de acessibilidade, escolha OpenLayers Se você precisar de visualizações de mapa, escolha * Here Se você precisar de mapas personalizados, escolha Mapbox Se você precisar de mapas Windows 10, escolha Microsoft Se você precisar de uma seleção variada, escolha MapQuest Artigos usados de referência: NORDIC APIS, programmableWeb, Geoawesomeness

Postado originalmente em Mundo API: https://mundoapi.com.br/materias/gerenciamento-de-apis/ A importância de um Gerenciamento de APIs em um mundo conectado. Um Gerenciamento de APIs é extremamente importante em um mundo digital e conectado, onde o seu produto deve estar presente e contextualizado através de múltiplos canais de atendimento, junto e com o seu cliente onde este estiver. Seu cliente pode estar em um shopping, assistindo televisão, dentro de um taxi ou mesmo em um elevador, não importa. Através de APIs ele será atendido e o seu produto estará presente onde ele estiver ou precisar, dando-lhe experiências únicas. Contudo, atender a vários canais não é uma tarefa fácil, tanto sob o ponto de vista do negócio, quando do ponto de vista técnico, pois cada canal pode possuir uma necessidade específica. Neste momento é que os Gerenciamentos de APIs atuam auxiliando ao seu negócio no mundo digital, dando inteligência através de relatórios, segurança, engajando com parceiros e inclusive acelerando o seu desenvolvimento. A importância de um Gerenciamento de APIs em um mundo de microserviços e APIs. Agora digamos que a sua empresa por mais insano que possa parecer, não pense em uma estratégia digital, não visualize APIs como produto, ou mesmo não deseja avançar em engajamento com parceiros e clientes via um Portal de APIs. Mas, deseja mudar aos poucos para microserviços, pois seu legado em termos de arquitetura, é custoso, não elasticamente escalável, complexo, altamente acoplado, não independente, ou qualquer outro motivo que afete a competitividade de sua empresa. O fato é que a sua TI deseja ir para uma arquitetura de Microserviços. Bem, neste momento, alguma coisa parecida a imagem abaixo surgirá. Repare nos Microserviços (MiS). Indo para uma visão um pouco mais de perto dos Microserviços (Cliente, Catálogo, Parceiro, Carrinho de Compras), visualize como eles se relacionam com o exterior: Percebeu? Na arquitetura de microserviços seu interfaceamento são através de APIs, muitas APIs! Imagine gerenciar todas essas APIs manualmente. Se preocupar com segurança, engajamento de desenvolvedores, Portal de APIs, transformação, mediação ou analisar o que está sendo trafegado. Muitas coisas para se preocupar! Tudo bem que você pode fazer tudo isso compondo vários produtos e frameworks, mas com um Gerenciamento de API, que veio para preencher essa lacuna, seu trabalho ficará no mínimo, muito mais fácil. Abaixo exploraremos. Com um Gerenciamento de API, as seguintes perguntas são facilmente respondidas: Quem mais utiliza as minhas APIs, dentre meus consumidores, de qual região do Brasil ou do mundo, ou mesmo dentro de minha empresa? Consigo analisar toda cadeia de execução de minhas APIs e identificar falhas de desempenho, payload? Consigo rapidamente atender a multicanais (wearables, IoT, apps diversas), cada qual com sua necessidade de consumo? Tenho segurança de uso de minhas APIs contra ataques de hackers ou acessos indevidos? Consigo criar um ecossistema de usuários para minhas APIs, onde a troca de informações será rica, com criação de inteligência coletiva, e esta dará aos participantes mais vontade de utilizar as minhas APIs? Funcionalidades existentes em um Gerenciamento de APIs Para entender ainda mais a importância de um Gerenciamento de APIs faço um resumo das principais funcionalidades que eles devem possuir: Portal para o Desenvolvedor: Este é responsável em engajar desenvolvedores, disponibilizar documentação, fornecer acesso seguro e adequado as APIs, criar comunidades, sandbox para testes e mecanismos para facilitar a adoção de suas APIs por desenvolvedores de apps. API Gateway: Bastante importante no momento de mediação entre os consumidores de APIs e seu backend. Muitas de suas funcionalidades são indispensáveis, como as de segurança (uso de OAuth\SAML, verificação de API Key, proteção de ataques XML\JSON, controle de acesso por IP), transformação (SOAP para REST, XML para JSON, JSON para XML, e transformação XSL), suporte a extensibilidade programática (no uso de linguagens de programação como Java, JavaScript, Nodejs) e por fim para controle de trafego ao seu beckend (como definição de quotas e cache). Gerenciamento do ciclo de vida de APIs: Necessário para facilitar e ter controle do processo que se inicia no design da API e engloba a publicação, versionamento e pôr fim a sua aposentadoria. Backend as a Service (BaaS): Permite com que desenvolvedores construam apps e utilizem as suas APIs com funcionalidades modernas como notificação por push, armazenamento de dados, monitoramento de desempenho, atividades sociais e gerenciamento de usuários. Este também disponibiliza SDKs nativos para diversas plataformas (iOS, Android, Ruby, Node.js, etc.). Um motor analítico: Este é muito importante para que você não tenha que fazer na mão as análises do que passou pelo seu API Gateway, tanto sob o ponto de vista de negócio, como técnico operacional. Vários relatórios devem compor um bom Gerenciamento de APIs, como relatório de uso de APIs, tempo de resposta do servidor de serviços, tempo de latência do seu proxy, relatório de erros, de APIs mais utilizadas, de payload por APIs, uso de por IP (e também por localização geográfica, por app, por período), entre outros relatórios que podem ser customizados pelo time de APIs através da ferramenta. Monetização: Se você pensar em monetizar a sua API, como falei em posts anteriores, esse item é indispensável, pois assim você poderá criar planos de monetizar para cada segmento ou mesmo cliente. Seus relatórios também são indispensáveis para você e seu parceiro de negócio. E quais as opções de Gerenciamento de APIs? Alguns Gerenciadores de APIs possuem todas as funcionalidades descritas acima, outros não. Alguns dizem que fazem, mas quando você analisa mais de perto é uma grande decepção, pois “fazem” através de customizações e no fundo são soluções básicas. Por isso é bom estudar direitinho o que cada um oferece. Para avaliá-los disponibilizo um formulário com mais de 130 perguntas que espero seja útil nesta hora. Utilize-o, mande para o fabricante do Gerenciador de APIs ou você mesmo poderá pontuar. Além do formulário acima, um item que todos esquecem na hora de aquisição de um produto de software é o total cost of ownership (TCO). O TCO responsável em dizer qual será o seu gasto para que o produto que você deseja comprar faça tudo aquilo que você realmente espera que este faça, inclusive para mantê-lo funcionando após a compra. Exemplificando o TCO: Imagine que o Produto A não tenha um relatório que combina dimensões de análise e você o deseja para o dia-a-dia. Nesta hora vem a questão: Quanto custará a mais se eu fizer este relatório? Ou, em outro exemplo de funcionalidade, se você desejar uma transformação que seja feita durante a mediação do Gateway, quando a mais será o investimento? Para responder essa pergunta o TCO deve ser pensado, mesmo que através de uma simples lista onde você comparará o que Produto A tem, seu concorrente não tem, que neste caso é o Produto B. Feito a lista de funcionalidades você deve das valores a cada item faltante, só assim você poderá chegar ao valor real do Produto B. Gerenciamento de APIs na versão Open Source ou Comercial Mas, e se você não quiser comprar um Gerenciador de API? Tudo bem! Apenas tome cuidado em relação ao TCO, pois se escolher errado este será alto, neste caso o máximo que você gastará é tempo. Contudo, de uma forma geral os open sources são ideais para startups na fase de MVP. Já as versões comerciais são mais completas e melhor aceita em empresas maiores, devido a gama de funcionalidades e ao suporte ao produto fornecido pelos fabricantes. Abaixo abordarei rapidamente apenas duas empresas que eu escolhi como referência de Gerenciamento de APIs, sendo que uma é comercial e outra open source. Para uma análise mais completa, você pode consultar o Gartner -Q4-2016 ou Forrester -Q4-2016. Comercial: Apigee (representada no Brasil pela SeedTS) – Simplesmente o melhor! O líder absoluto em quantidade de clientes e APIs publicadas e que processa cerca de 2 bilhão de transações dia é a Apigee apenas na versão cloud, comprada no ano passado pela Google. Suas funcionalidades e facilidade de uso são incomparáveis e anos luz a frente da concorrência. Eu mesmo utilizo Apigee em projetos e a cada dia acho mais sensacional, principalmente após a compra da Google, pois ficou mais barato e extremamente convidativo, pois você possui um produto completo sem se preocupar com a escalabilidade e confiabilidade da infraestrutura, com a garantia da maturidade do produto e por fim com cases globais de alto volume, seja em bancos, telecons ou nas 20 das 100 maiores da Fortune que utilizam Apigee. Aqui no Brasil o maior case da Apigee é com o Magazine Luiza, que processa 1,1 bilhão de transações mês, através de mais de 100 APIs. Open source: WSO2 – Dos gratuitos o melhor! Para aqueles que procuram um produto maduro e open source, o WSO2 é a melhor opção. Se você desejar baixar e simplesmente utilizar você pode. O melhor é que não tem que pagar nada para ninguém! Se, contudo, quiser utilizar o mesmo produto hosteado na cloud WSO2 aí não tem mágica, tem que desembolsar um dinheirinho. Mas, de olho no TCO! Um ponto forte do WSO2 é quando se deseja uma solução de produtos integrados com outras linhas de softwares da WSO2, como o WSO2 Enterprise Service Bus e WSO2 Identity Server. Neste cenário o WSO2 passa a ser uma excelente opção e no Brasil seu o maior case é o Serpro. Bem, agora que você sabe que a sua estratégia digital não pode ser completa sem um Gerenciamento de APIs corra para utilizar um, seja open source ou não. O fato é que esta ferramenta veio para economizar um bom tempo seu e acelerar a estratégia de transformação digital de sua empresa. Obs.: Abaixo inseri uma lista não exaustiva, de outros player de Gerenciamento de APIs open source e comercias. Gerenciamento de APIs Comerciais: Apigee IBM API Management Microsoft API Management Oracle API Management CA API Management MuleSoft Akana-RogueWave Gerenciamento de APIs Open Souce: WSO2 Kong API Umbrella Tyk

Postado originalmente em Mundo API: https://mundoapi.com.br/destaques/como-identificar-o-que-um-consumidor-ou-politico-esta-sentindo-aqui-um-exemplo-do-aecio-neves-com-a-linguagem-r/ Aqui um exemplo do Aécio Neves, com a linguagem R. Aécio Neves é um político importante no Brasil, agora como todos sabem está no centro das atenções. Por muito pouco não foi eleito Presidente da República em 2014 e é certamente um nome bem influente na atualidade. Mas sério, toda vez que eu vejo esse cara falando, não dou a mínima para quem ele é. Eu apenas fico pensando: ‘Por que ele sempre faz tanta cara de dor?’ Pensando nisso, decidi pegar algumas fotos famosas dele e aplicar um algoritmo de Inteligência Artificial para reconhecimento de emoções. Se minha hipótese estiver correta, provavelmente esse algoritmo retornaria emoções como “dor”, “tristeza” ou “descontentamento”. A API escolhida para essa tarefa foi a Microsoft Emotions API. O motivo por trás da escolha não é nada especial: foi o primeiro resultado que apareceu no Google para mim! As imagens utilizadas para testar o algoritmo contra minha hipótese são essas aqui: Obtenção das emoções Como dito, para utilizar tal API utilizamos a linguagem R e os pacotes carregados para essa análise foram: library(tidyverse) library(httr) library(grid) library(gridExtra) Para obter os resultados, foi necessário entrar na página de APIs de visão da Microsoft e obter uma chave de acesso, guardando-a no objeto key. Depois disso, montei a função pegar_emocoes(), que recebe a URL de uma imagem da internet e uma chave de acesso, e retorna uma tibble com as proporções das emoções em cada coluna. pegar_emocoes <- function(u_img, key) { u_api <- 'https://westus.api.cognitive.microsoft.com/emotion/v1.0/recognize' result <- httr::POST( url = u_api, httr::content_type('application/json'), httr::add_headers(.headers = c('Ocp-Apim-Subscription-Key' = key)), body = list(url = u_img), encode = 'json' ) tibble::as_tibble(httr::content(result, 'parsed')[[1]]$scores) } Finalmente, apliquei a função num vetor de links usando o funcional purrr::map_df. ## recomendo adicionar a API key no arquivo ~/.Renviron ## EMOTION_API= ## (necessário pular linha no final do arquivo) key <- Sys.getenv('EMOTION_API') d_emocoes <- map_df(u_imagens, pegar_emocoes, key = key, .id = 'id') Resultados A Figura 1 mostra a média de cada emoção nas seis fotos. Para minha surpresa, a emoção com maior proporção média foi “neutro”, com peso de quase 50%. As emoções seguintes são “felicidade”, “raiva” e “desdém”. A emoção “tristeza”, que achei que seria frequente por conta da cara de dor do Aécio, ficou com uma proporção média de apenas 5,5%. Figura 1 Média de cada emoção nas seis fotos baixadas. A Figura 2 mostra os resultados individuais das imagens. O primeiro resultado faz sentido, já que o Aécio está nitidamente rindo. Em todos os casos, é possível interpretar os resultados olhando a imagem. Por exemplo, o caso com “tristeza” mais alto é o que observamos as sobrancelhas mais caídas. Figura 2 Emoções do Aécio em cada imagem. Conclusão Aparentemente minha hipótese estava errada. Aécio é um cara neutro e feliz, com acessos raiva de vez em quando (por favor, não interprete isso seriamente, é uma brincadeira!). Mas, sinceramente, achei que faltou na API uma emoção “cara de dor” para captar perfeitamente a expressão do Aécio. De qualquer forma, foi uma análise rápida e muito divertida de fazer. Se quiser replicá-la para outras imagens, acesse o código fonte no repositório do GitHub que gera esse site. É isso. Happy coding 😉

Postado originalmente em Mundo API: https://mundoapi.com.br/destaques/como-fracassar-no-business-basta-ignorar-apis/ Miopia de Marketing e APIs. Ou o seu negócio se conecta ou está fora… As Web APIs ou simplesmente APIs, já saíram apenas do universo de técnicos como eu e você, que provavelmente está lendo este post, e está entrando no mundo dos negócios ou na cabeça de profissionais que se preocupam em não deixar o negócio afundar. Informação valiosa: quem ainda não percebeu a importância de APIs em seu negócio, sofre de Miopia de Marketing. O termo Miopia de Marketing foi escrito por Theodore Levitt em 1960 e foi exemplificado através da desvalorização de várias empresas como Kodak, que não se mexeu em tempo quando a Sony lançou uma câmera digital que dispensava o uso de filmes. Mesmo a Mesbla, que não percebeu com a velocidade necessária o surgimento de empresas especializadas como C&A (moda e vestuário) e Ponto Frio (eletrodomésticos), assim como a descentralização de lojas alcançando bairros, ao invés de gigantes que vendiam tudo nos centros urbanos. Todas que sofreram de miopia de marketing ou afundaram ou perderam mercado. Hoje temos movimentações de inovação muito mais aterrorizantes para grandes empresas. Temos a economia de APIs, economia de acesso, negócios disruptivos, cultura de startups e todo um ambiente propício para que novas empresas surjam, como o aumento de banda de internet, poder de processamento de hardware, computação em nuvem e maior velocidade de desenvolvimento. Tudo isso faz surgir novos produtos, onde antes não era possível, como exemplo wearables de IoT. Hoje um desenvolvedor pode criar um app que utiliza um conjunto de APIs, publicar em um servidor em nuvem, pagar um valor que está em seu orçamento e concorrer com empresas gigantes que não possuem a velocidade ou a visão de marketing apropriada. Para os técnicos de empresas que já visualizam o uso de APIs em diversas aplicações e também perceberam que internamente APIs é um assunto deixado de lado, segue algumas alternativas: Mostrar onde APIs estão sendo aplicadas pelos concorrentes, seja no Brasil ou exterior; Falar sobre Miopia de Marketing em APIs; Ver a possibilidade de sua empresa se esfarelar ao não implantar uma estratégia de API, pois os carros ultrapassarão os trens (referência ao artigo de miopia de marketing). APIs que geram receitas As APIs não servem apenas para documentar ou deixar o seu CIO feliz e de bem com o board dizendo que está alinhado com as novas tecnologias. Elas servem estrategicamente para o seu negócio. As APIs são os interfaceamentos do meio digital onde o seu negócio opera e delas pode-se obter muitas informações úteis ao seu negócio durante sua execução. Se sua empresa utiliza APIs para comprar insumos para sua indústria, fazer cotação de seguros, reservar passagens, verificar a logística, ou mesmo disponibiliza publicamente suas APIs, tudo poderá ser analisado. Entenda como utilizar as informações que trafegam pelas APIs, como monetizá-las, como fazê-las parte da estratégia digital de sua empresa. Se você definir que a receita de seu app virá também (ou exclusivamente) através de sua API, seja de forma direta ou indireta, você precisará ter um modelo de monetização com APIs. Como Monetizar com APIs? Monetizar é a forma como você irá gerar receitas com APIs. Neste tópico, uma palestra feita por John Musser em 2013 condensou várias formas de monetização com APIs: Musser aborda a monetização de várias maneiras, desde a do tipo onde o desenvolvedor paga (ex. bolsafinanceria) para utilizar a API do provedor ou é pago para tal (ex.: Dev Lomadee). Neste último caso, ocorre quando o consumidor gera receita para o provedor de API. Também explica tipos de monetizações indiretas quando o produtor de APIs utiliza as APIs para geração de trafego ao seu site, entre outros modelos de monetização. O principal recado aqui é: Desenhe a forma como irá monetizar através do uso de sua API, e isso não significa vender diretamente através de APIs. Encarando sua API Como Produto Contudo, antes mesmo de monetizar o que é importante, é você encarar a sua API como produto, mesmo que ela esteja associada ao seu app ou produto principal de sua empresa. Desta forma, você deve entender as necessidades de mercados, pontos fortes e fracos de seus concorrentes, definir como atenderá seus clientes potenciais e desenhar sua estratégia com APIs. Ou seja aplicar marketing em sua API. Muitas startups já sabem o conceito de MVP, Canvas para seu negócio e como utilizar métricas para acompanhar o engajamento. Usem para APIs! Se fossemos fazer um canvas para um app web de hub de sensores que disponibilizassem APIs, que fossem utilizadas dentro de uma plataforma IoT, por exemplo, seu esboço seria este: Repare que a partir de seu canvas e tendo em mente APIs, você poderá desenhar o conjunto de APIs que serão necessárias para interoperabilidade com fabricante de sensores, clientes, parceiros e também terá uma ótima ideia de como monetizar. Fortificando: Se você não sabe como irá modelar a sua API ou como será o valor que entregará aos consumidores de suas APIs, comece pelo canvas. Canvas Ok, API como Produto Ok e depois? Após definir direitinho a sua API como produto (que é o mais importante), você pode voltar a ser técnico e utilizar a estratégia de API First com Swagger ou RAML e seguir na implementação RestFul, utilizando API Gateway, Portal de API e por fim medir o engajamento. Em próximos posts exploraremos tais assuntos. Bem, resumindo não deixe de pensar na sua API como produto, a menos que você deseje apenas documentar seus RestFuls de forma organizada via um portal de APIs, mas como sabemos isso é muito pouco para o seu potencial de uso. Pense em novas formas de adicionar receitas ao negócio com estratégias de monetização, além de utilizá-las para que você conheça muito mais seu negócio, pois lembre-se que elas são as interfaces para se conectar com o mundo. Links úteis: Miopia de Marketing https://pt.wikipedia.org/wiki/Miopia_em_marketing Canvas https://pt.wikipedia.org/wiki/Business_Model_Canvas MVP https://pt.wikipedia.org/wiki/Produto_vi%C3%A1vel_m%C3%ADnimo John Musser https://www.slideshare.net/jmusser/j-musser-apibizmodels2013

Postado originalmente em Mundo API: https://mundoapi.com.br/destaques/cpaas/ O que são CPaaS? CPaaS é o acrônimo de Communications Platform as a Service (ou Plataforma de serviços de comunicação). Os CPaaS disponibilizam serviços de voz, vídeo e mensagem de comunicação baseados em nuvem, o que permitem que desenvolvedores os utilizem em suas aplicações via APIs, sem a necessidade de ter por traz toda uma infraestrutura complexa. Com os serviços das CPaaS uma aplicação pode ter funcionalidades de comunicação para criar valor a produtos, visando atender melhor ao usuário final. Seu papel também é fornecer toda a documentação e suporte para ajudar o desenvolvedor a utilizar seus serviços onde este, no final das contas, são seus clientes. Desta forma os CPaaS investem em Portal de API, disponibilizam SDKs, bibliotecas e todo o encantamento para que o desenvolvedor utilize ainda mais seus serviços. Possibilidades de uso nas mais diversas aplicações A aplicabilidade de tais serviços é vasta e só tende a crescer nas mais diversas aplicações, atendendo a um variado ramo de negócios. Imagine poder disponibilizar em qualquer aplicação um chat em vídeo. Que tal se este chat fosse entre a portaria de um prédio e o elevador ou mesmo com a sua TV, ou entre um painel de um carro e uma smartphone ou embarcado em um IoT? Ou mesmo em uma linha de produção de uma fábrica? Ou entre enfermeiros e médicos em hospitais? Tudo isso é possível através de uso de APIs de WebRTC (Web Real Time Communications) que os CPaaS disponibilizam de uma forma mais fácil através de APIs. O que é o WebRTC? O WebRTC são utilizados em vários apps como Facebook, WhatsApp, navegadores do iOS e Android, e é um padrão w3c. Com esta biblioteca é possível abrir um canal de comunicação e fluxo de transferência de dados via navegadores, através do uso das seguintes APIs: MediaStream: responsável em criar a sincronização de fluxo de media, com acesso a câmera e microfone; RTCPeerConnection: responsável pela conexão ponto-a-ponto, com a característica funcional de gerenciamento de banda e criptografia do transmitido; RTCDataChannel: responsável em criar canais bidirecionais ponto-a-ponto, inclusive para a transferência de dados. Por onde começo para integrar os serviços de comunicação em minha aplicação? Você pode utilizar as APIs do WebRTC ou as APIs de CPaaS, a diferença é o esforço e o investimento que você deseja fazer e o tipo de aplicação. Para quem deseja gerar valor ao seu produto rapidamente e com um menor esforço de implementação é melhor utilizar os serviços de CPaaS. Neste caso será necessário assinar os serviços das CPaaS o que implica em custos. Figura exemplo de empresas CPaaS Já para aqueles que desejam dominar completamente o assunto e fugir dos pagamentos mensais, o ideal é começar com as bibliotecas do WebRTC, SIPjs, ou Jitsi.org. O ponto positivo é que assim o desenvolvedor tem a liberdade para criar o que quiser, como integrar com plataforma específicas de VoIP como Freeswitch, Asterisk criando soluções de telefonia completas. Contudo, dependendo do que se deseja criar, terá que investir mais em desenvolvimento e infraestrutura, o que pode gerar muito mais custo no final do projeto que as versões pagas em CPaaS. Exemplos de uso do WebRTC-SIPJs e WebRTC Bem, daqui em diante você poderá utilizar as APIs de CPaaS ou criar a seu próprio site de vídeo conferência entre outras coisas mais, com as APIs de WebRTC. Até, Antonio Bruce (Linkedin) Para utilizar bibliotecas de comunicação: https://webrtc.org/ https://sipjs.com/ https://jitsi.org/ http://www.w3.org/TR/webrtc/ Github- w3c https://github.com/w3c/webrtc-pc Tutorial WebRTC: https://webrtc.org/start/ Seviços CPaaS: https://www.twilio.com/ https://www.telesign.com/ http://www.totalvoice.com.br https://developer.onsip.com/

Postado originalmente em Mundo API: https://mundoapi.com.br/materias/como-negocios-podem-se-beneficiar-de-design-api-first/ Existem duas tendências divergentes ocorrendo no desenvolvimento mobile agora. A mais comum é a abordagem mobile first, na qual a prioridade de planejamento para desenvolvimento de projetos web parte de dispositivos móveis. A outra tendência é a abordagem API First, na qual a construção subjacente – ou seja, a camada de APIs – é construída primeiro. Essa estratégia permite que sites e aplicativos em várias plataformas sejam construídos em cima das mesmas condições básicas. Se o seu público-alvo for exclusivamente usuários do iOS, talvez uma estratégia de mobile-first funcione para você. No entanto, a desvantagem é que isso dificulta o rápido desenvolvimento para futuras audiências, incluindo Windows, Android e um aplicativo da web para seus usuários não móveis. A solução de API First permite que os desenvolvedores de aplicativos alcancem rapidamente assinantes em muitos dispositivos diferentes. Com esta estratégia, você pode criar, implantar e gerenciar todo o ciclo de vida do dispositivo mobile a partir de uma fonte usando um API Backend as a Service (BaaS). Talvez o mais importante é visualizar que o BaaS permite que você economize tempo e dinheiro ao escalar seu negócio rapidamente. E, de acordo com a Markets and Markets empresa de pesquisa de mercado, BaaS será um mercado $ 7,7 bilhões até 2017, por isso vemos BaaS como uma aposta segura. Abaixo você confere algumas maneiras que seu negócio pode se beneficiar da estratégia API First: APIs como fonte de receita adicional: Um restaurante divulga seu menu diário e disponibilidade para reservas via API. Um desenvolvedor terceiro como Yelp ou TheFork gostaria de acessar essa informação. O restaurante pode escolher deixar a API gratuita por motivos de branding, cobrar cada vez que a informação for requisitada ou simplesmente criar uma cobrança mensal. APIs aumentam o awareness da marca: O TripAdvisor usa Mulesoft para expor sua API que tornar disponíveis fotos, reviews e classificações, assim como a Hotel Availability Check API. Fora do site do TripAdvisor, aqueles olhos de coruja hipnóticos deixam centenas de milhares de impressões da marca diariamente. APIs aceleram inovação aberta: O rastreador fitness Fitbit abriu sua API em 2011 para permitir desenvolvedores terceiros criarem apps fitness baseados em seus dados de saúde. Mais de 20 apps foram criados nos primeiros dois anos, fazendo com que a Fitbit economizasse 1 milhão de dólares em P&D. APIs elevam a eficiência: Uma abordagem de design API First ajuda muito a estruturar internamente seu sistema e arquitetura de TI, além de auxiliá-lo em melhorias na manutenção da sua arquitetura. Isso também é conhecido como “comer a comida do seu próprio cachorro” – você maximiza a eficiência e continua melhorando sua API internamente.

Postado originalmente em Mundo API: https://mundoapi.com.br/materias/por-que-voce-deve-conhecer-a-open-api-iniciative-com-swagger/ A Open API Initiative (OAI) é uma iniciativa focada em criar, evoluir, engajar e promover um formato de especificação de APIs open source baseado em Swagger, a ser utilizado por produtores de APIs e fornecedores neutros de softwares comerciais. Trata-se de uma representação poderosa e fácil de aprender que o desenvolvedor pode utilizar em projetos para documentar suas APIs REST. A especificação do Open API é aberta e está no GitHub, pode ser utilizada sem que seja necessário pagar por seu uso, assim como participar sendo contribuinte de sua especificação, bastando para tal se cadastrar no fórum de especificação do site. Empresas como MundoAPI (sim! nos cadastramos como membros), Apigee, Intuit, Paypal, Microsoft, Google, 3Scale, participam da iniciativa OpenAPI. Estas e muitas outras já entenderam que esta iniciativa é importante para a padronização do uso e da documentação de APIs, feita com Swagger. Abaixo listamos ferramentas e projetos Swagger para criação e manipulação de especificação de APIs: A ferramenta mais importante na hora de especificar a sua API é o Swagger Editor. Este tem um papel fundamental na estratégia e abordagem API First, onde a criação do software se inicia na concepção de um conjunto de APIs, que são importantes tanto para a interoperabilidade entre sistemas como para o negócio. Com API First em mente e com o Swagger Editor, o desenvolvedor deve especificar o seu conjunto de APIs logo no início do projeto, desta forma seu sistema já estará concebido para atender a diversos tipos de clientes possíveis, como mobile, IoT, Web, etc. Após a especificação das primeiras APIs, o desenvolvedor pode utilizar o seu gerenciamento de APIs favorito. A líder nas três últimas edições do Gartner é o Apigee Edge da Google, originalmente da empresa Apigee, que foi comprada pela Google em 2016 e representada no Brasil pela SeedTS. O Apigee Edge utiliza a especificação de API padrão Swagger como uma das alternativas para a criação de API Proxy em sua plataforma. Além de ser mais rápido a criação do API Proxy, esta já fica com a documentação gerada durante a fase de especificação (lembra do API First?). O mesmo Swagger também será posteriormente útil para o desenvolvimento do backend e esta abordagem chama-se top down. No passado não muito distante com uma abordagem semelhante, a de modelagem canônica em SOA, existia uma grande dificuldade e trabalho extra de conversão, entre contrato de serviço em formato word e o código. Já com o auxílio de ferramentas que seguem a OpenAPI esse caminho é suave e automático. Como exemplo, na figura abaixo se encontra ao lado direito a especificação Swagger e no esquerdo a documentação gerada automaticamente. Após esse passo, o desenvolvedor pode também gerar a sua API Proxy em um clique no gerenciador de APIs, o que torna o trabalho top down muito mais rápido. Mas, se quiser mesmo gerar tudo até o serviço de backend ou mesmo clientes, pode-se usar o Swagger CodeGen. Uma outra abordagem é a bottom-up, que basicamente é o inverso da top-down. Na bottom-up usualmente se expõe o legado via APIs Proxies também em um gerenciador de APIs junto com a sua documentação Swagger. Ah! Uma informação adicional: A mesma documentação gerada para a API será útil para o seu Portal de APIs. Portais de APIs possuem o papel de se relacionar com os desenvolvedores internos e externos, assim como gerenciar o permissionamento e autorização para o uso das APIs, que você criou com tanto afinco! Bem, agora você sabe que Open API Initiative é uma iniciativa aberta e que utiliza o Swagger como elemento principal para especificação de APIs, agora você pode começar aplicando API First e utilizando o Swagger na abordagem top-down! Boa API!

Postado originalmente em Mundo API: https://mundoapi.com.br/materias/como-vencer-na-economia-de-apis/ Dez anos atrás, qualquer empresa pequena ou grande sem um website não era vista como um empreendimento sério. Hoje, o mesmo se torna verdade para os negócios que não conseguem tirar vantagem das APIs – esses simples e poderosos bits de código que permitem serviços e aplicações digitais se comunicarem uns com os outros. Empresas líderes em suas indústrias estão reinventando seus negócios em códigos, gerenciando APIs como produto e como núcleo do negócio, ao invés de tratá-las como mais um projeto de TI. Usuários web e mobile cresceram junto com as APIs, interagindo com elas inúmeras vezes todos os dias, veja só: sem as APIs, a forma transparente como o Google Maps se integra às pesquisas no Yelp seria inimaginável! Kyle Charlet engenheiro e arquiteto cloud e Jason Gartner CTO, discutem aqui como a Economia de APIs permite inovação na velocidade da luz – enquanto ajuda a transição dos negócios de ecossistemas digitais para cognitivos. 1. Assim como muitas frases associadas com a tecnologia digital, “A Economia de APIs” parece ter significados diferentes para pessoas diferentes. O que essa frase significa sob sua perspectiva? Kyle Charlet: APIs permitem aos aplicativos e sistemas se conversarem. Existem APIs para consumidores e qualquer pessoa que utilize um dispositivo móvel – sabendo ou não o que é uma API – e há o que chamamos de APIs internas, que uma empresa pode utilizar para trocar dados com suas aplicações dentro de seu próprio ecossistema. Em sua forma elementar, a Economia de API permite aos negócios monetizarem suas APIs e serviços. 2. Mais do que apenas dinheiro é trocado através das APIs, correto? Jason Gartner: Está correto. Algo que faz da Economia de API única é que vários tipos de moedas circulam entre desenvolvedores de APIs e consumidores, e nem todos eles envolvem diretamente o dinheiro em espécie. Existem momentos em que um website irá pagar ao provedor alguns centavos todas as vezes que ele precisar utilizar a API. Mas outros tipos monetários também são trocados, por exemplo, o login do Facebook que autentica usuários em tantos outros sites é uma API, e o consumidor da API é o website que oferece essa facilidade de login. A moeda trocada é propaganda gratuita para o Facebook, o que aumenta o valor da sua plataforma porque milhões de usuários agora estão efetuando login em diversos sites todo dia. Definitivamente não há a troca de moeda, mas ocorre uma troca de valores. 3. Jason, a Economia de API vai dar força à próxima grande transição das empresas, do modelo digital para o modelo cognitivo? Jason Gartner: Bem, certamente o número de APIs que são chamadas pelas máquinas, em contraposição às chamadas efetuadas pelas pessoas através de um aplicativo no desktop ou dispositivo móvel é exorbitante. Isso significa que uma quantidade gigante de atividade cognitiva está ocupando lugar entre os negócios sem qualquer tipo de intervenção humana direta. Pense sobre o processo de empréstimo entre uma concessionária de automóveis e um banco. Na maioria dos casos, não há mais uma pessoa envolvida nessa interação. As APIs estão buscando as informações do seguro, da carteira de motorista, os últimos três lugares aonde o comprador morou, atividade em mídias sociais, e muitos outros tipos de dados – tudo simultaneamente. E esses dados não são binários simples, ou booleanos (sim-ou-não), eles são dados cognitivos, com computação mais ágil, criptografia mais forte e terabytes de memória para diminuir a latência, essas transações são mais rápidas e mais seguras do que nunca. Tudo utilizando APIs. 4. Com o Open Source trazendo tanta inovação e com tantas APIs surgindo no mercado a cada dia, como os negócios vão saber quais APIs irão vingar e quais serão esquecidas daqui a seis meses? Kyle Charlet: A Economia de APIs não é somente sobre as próprias APIs, mas também como descobrir qual API que se encaixa em seu negócio, seja no presente ou futuro. Os padrões abertos facilitam o trabalho de escolha, pois permite que todos caminhem para o mesmo lugar com poucas dúvidas e isso é muito bom, pois dá segurança e consistência ao ecossistema. Claro, que para aqueles que implementam padrões abertos, sabemos que nem todas as APIs são criadas internamente da mesma forma. Aquelas que são mais usadas tendem a ser as mais confiáveis, se você utilizar três APIs que fazem exatamente a mesma coisa e duas delas estão fora do ar por 10% ou 20% do tempo, você irá naturalmente utilizar a que sempre funciona. Esse é um ponto de valor importante na proposta que se deve buscar em plataformas de APIs: a confiabilidade. Traduzido e adaptado de: FastCompany