Muito trabalho precisa ser feito para implementar a API. O planejamento excessivo pode ser um desperdício de energia e sua falta leva a conseqüências desastrosas. Neste livro, você receberá soluções que permitem alocar os recursos necessários e atingir o nível de eficiência exigido no tempo ideal. Como equilibrar flexibilidade e desempenho, mantendo confiabilidade e facilidade de configuração? Quatro especialistas da API Academy explicam aos desenvolvedores de software, gerentes de produto e projeto como maximizar o valor de suas APIs, gerenciando interfaces como produtos de vida contínua.
O material do livro é baseado em nosso conhecimento coletivo (Mehdi Mejuy, Eric Wilde, Ronnie Mitra, Mike Amundsen) ao longo de muitos anos criando, desenvolvendo e melhorando a API - tanto a nossa quanto a de outras pessoas. Estabelece toda a nossa experiência. Identificamos dois fatores principais para o desenvolvimento efetivo da API: a necessidade de uma abordagem orientada ao produto e a formação da equipe certa. Também identificamos três fatores importantes para gerenciar este trabalho: liderança, desenvolvimento de produtos e desenvolvimento de sistemas API.
Esses cinco elementos formam a base sobre a qual criar um programa de gerenciamento de API bem-sucedido. Apresentamos ao leitor todos esses tópicos e fornecemos orientações sobre como encaixá-los no contexto da sua organização.
Trecho. Sistemas API
Com a crescente funcionalidade da API, está se tornando cada vez mais importante gerenciar programas em desenvolvimento para que os benefícios e o valor de todo o conjunto de APIs da organização cresçam ao máximo. Você precisa se lembrar desse equilíbrio, porque a melhor (ou relativamente boa) maneira de fornecer um serviço individual usando a API pode não ser tão útil, se você olhar para ele do ponto de vista da facilidade de usar esse serviço como parte de um sistema comum.
Os sistemas de API modernos estão em constante crescimento em termos do número total de APIs, bem como do número de APIs usadas por novos serviços. Dado esse aumento nas interdependências, entendemos que seria útil se os desenvolvedores de novos serviços não precisassem entender os designs de API completamente diferentes e aplicá-los. As diferenças podem ser dramáticas - por exemplo, se a API usa um estilo REST ou orientado a eventos (consulte a seção Design da seção Introduzindo os Pilares do Capítulo 4) - mas mesmo que os estilos correspondam, diferenças como o uso do formato JSON podem ser detectadas ou XML.
Do ponto de vista de um usuário da API, também seria útil ter uma terminologia comum. Por exemplo, se você usar várias APIs que fornecem dados do usuário de qualquer forma, será mais fácil se todos eles tiverem um modelo principal de usuário (mesmo que seja apresentado de maneira ligeiramente diferente, no entanto, é útil ter um modelo comum para serviços diferentes) .
A idéia dos benefícios da padronização indica claramente que quanto mais, melhor. Até certo ponto, é verdade, mas, ao mesmo tempo, sabe-se que a padronização demanda tempo e recursos, mas geralmente não se resume ao "único modelo verdadeiro e melhor", mas simplesmente cria um modelo com o qual todos podem chegar a um acordo. e, portanto, em geral, esse investimento apresenta riscos e vantagens.
Talvez o uso de um formato exclusivo para cada API não seja a melhor solução, seja mais razoável escolher os existentes, por exemplo, JSON ou XML. Nesse caso, os benefícios da aplicação dos padrões existentes superam os benefícios prováveis de formatos exclusivos. No entanto, pode ser muito caro padronizar alguns elementos de diferentes serviços, por exemplo, o modelo de usuário já mencionado. Nesse caso, é lógico não ir para essas despesas injustificadas com o objetivo de encontrar o único modelo de usuário verdadeiro e parar no modelo de domínio.
De um modo geral, idealmente para cada serviço, queremos não reinventar a roda quando não for necessário, mas reutilizar os elementos de design que reduzem o custo de recursos para criar um design, seu entendimento e implementação. Se conseguirmos alcançar um nível ideal de re-aplicação, ou pelo menos nos aproximarmos dele, isso permitirá que os criadores de serviços se concentrem nos aspectos do design que precisam ser focados sem se distrair com os problemas já resolvidos.
Vemos cada vez mais organizações fazendo exatamente isso. Mas o mais importante é entender e garantir que os manuais para designers sejam atualizados constantemente: novos métodos são avaliados e aprovados, métodos antigos saem de circulação e a principal força motriz por trás dessas mudanças é o conjunto de métodos API em constante evolução na organização.
É importante entender que o sistema de API é um ambiente móvel e em constante mudança e, para continuar funcionando, a arquitetura deve seguir o mesmo caminho de desenvolvimento contínuo. Então, torna-se um sistema de grande escala, por exemplo, a Internet, que, por um lado, funciona o tempo todo e, por outro lado, muda constantemente e novos padrões e tecnologias emergem constantemente.
API de Arqueologia
Embora agora vejamos um grande número de organizações que estão apenas começando a criar programas com APIs, é importante lembrar que em qualquer organização que usava tecnologia da informação, há quase certamente algumas APIs usadas há muito tempo.
Com base na definição, uma API é qualquer interface que permita a interação de dois componentes de software. Se você restringir a definição a um entendimento moderno da API da rede, essa é qualquer interface que permita que dois componentes de software interajam pela rede.
Em muitas organizações, essas interfaces não são chamadas de APIs e não são projetadas para serem reutilizadas (lembre-se da história sobre o famoso termo de API de Jeff Bezos, que contamos na subseção de Bezos da seção Design Thinking do Capítulo 3). Mas, na maioria das vezes, essas interfaces existem, mesmo que tenham sido criadas e usadas para integração apenas para um único uso (comprometendo essa uma das principais propriedades úteis da API - a possibilidade de reutilização).
Encontrar e aplicar essas proto-APIs pode ser útil porque mostra onde surgiu a necessidade de integração (mesmo que tenha sido criada usando métodos que não atendiam aos objetivos da API). Nem todas essas proto-APIs devem ser substituídas por APIs convencionais, mas apenas pela compreensão do histórico, você pode obter idéias sobre como a necessidade de integração foi observada, o que foi feito nessa área e onde a necessidade de integração adicional pode aparecer.
API PROTO
A necessidade de interação de componentes existe em todos os sistemas complexos que consistem em partes separadas. Uma API é uma maneira de fazer isso, mas existem muitas outras. Do ponto de vista da API, qualquer mecanismo usado para a interação de componentes que não são uma API pode ser considerado uma proto-API. Em um sistema ideal, usando a API, todas as interações de componentes são executadas sem exceção. Se você se lembra dessa imagem ideal, qualquer interação sem a ajuda da API se torna candidata à modernização - para ser substituída por uma API. Portanto, qualquer mecanismo para a interação de componentes sem a ajuda de uma API pode ser considerado uma proto-API.
Em geral, a arqueologia da API pode ajudá-lo a entender melhor o sistema da API, mesmo que agora consista principalmente em proto-APIs. Ele fornece um ponto de partida para entender a necessidade de integração surgida no passado e para quais investimentos em API é possível desvendar melhor a rede problemática de muitas integrações de usuários. Com a experiência e o tempo, a substituição de integrações criadas antes do advento da API por modelos modernos está se tornando cada vez mais fácil.
Gerenciamento de API em larga escala
O gerenciamento de API em larga escala é o ato de equilíbrio entre a introdução de um design comum no nível do sistema e a maximização da liberdade de escolha de design no nível da API individual. A escolha entre integração centralizada para consistência e otimização e descentralização para flexibilidade e desenvolvimento é um problema comum em um sistema complexo.
- A integração centralizada nos trouxe a arquitetura de TI corporativa típica do passado. A principal força motriz foi a padronização da execução das funções, a fim de proporcionar a elas de forma otimizada e com custo mínimo. Um alto nível de integração realmente simplifica a otimização, mas ao mesmo tempo afeta a capacidade de fazer alterações e desenvolver o sistema final.
- Descentralização é o oposto. O exemplo mais acessível e em larga escala disso é a Internet. A principal força motriz aqui é a padronização do acesso às funções, para que você possa fornecê-las de muitas maneiras diferentes que estão em constante evolução. Ao mesmo tempo, as funções permanecem disponíveis, pois o acesso é baseado em acordos gerais sobre a interação de funções. O principal objetivo da descentralização é enfraquecer a coerência ( http://bit.ly/2FpcUpf ), ou seja, facilitar as alterações em partes individuais do sistema geral sem a necessidade de alterar outras partes.
DESCENTRALIZAÇÃO E EXECUÇÃO
Se aprendemos algo com as promessas incompletamente cumpridas da época de uma arquitetura orientada a serviços baseada em SOAP, a execução gerenciada com cuidado é um aspecto essencial da implementação de perspectivas orientadas a serviços. O SOAP cumpriu a promessa de fornecer acesso às funções, mas não lidou com a tarefa igualmente importante de gerenciar adequadamente a execução das funções. Portanto, embora o SOAP fosse útil (funções que antes estavam indisponíveis apareciam como serviços), ele não atendia às necessidades de um ambiente mais flexível e em evolução.
A complexidade do gerenciamento do sistema de API é lembrar esse problema e evitar a armadilha em que o SOAP caiu. O SOAP disse que apenas a disponibilidade dos serviços é importante. Este foi um primeiro passo importante, mas não permitiu lidar com a fraca coerência de funções. As APIs e, se você se concentrar especialmente nas técnicas de implementação e implantação, os microsserviços nos permitem repensar o que é importante para grandes sistemas de serviço e como criar sistemas que não caem na armadilha SOAP.
Princípio da plataforma
Muitos falam sobre plataformas, discutindo APIs e principais objetivos de negócios. No entanto, eles podem significar coisas completamente diferentes. É importante lembrar: se, no nível de negócios, parece uma boa idéia criar algo como plataforma, isso não significa que é assim que deve ser desenvolvido em nível técnico.
No nível comercial, a plataforma fornece algo sobre o qual construir algo, e não podemos ir mais fundo do que essa redação bastante vaga. Freqüentemente, a atratividade do conceito de “plataforma” é influenciada por dois fatores principais.
- Qual é a cobertura da plataforma? Ou seja, quantos usuários podem ser alcançados criando algo nesta plataforma? Isso geralmente é determinado pelo número de usuários ou assinantes. Frequentemente, esse é o parâmetro mais importante, calculado pelo número total ou usando fatores qualitativos que determinam os usuários certos, que podem ser abordados usando esta plataforma.
- Quais recursos essa plataforma possui? Se você criar algo, como isso o ajuda ou o limita em termos de renda? E também é fácil alterar a plataforma para adicionar novos recursos, idealmente sem prejudicar seus usuários?
Esses parâmetros são muito importantes para os negócios, mas há um fator que é frequentemente esquecido: as plataformas sempre forçam os usuários a aderir a certas restrições, mas fazem isso de maneiras diferentes. Aqui estão alguns exemplos.
- Os aplicativos da Web podem ser usados por qualquer pessoa e qualquer coisa que atenda aos padrões básicos de rede. No caso mais simples, este é um navegador moderno com suporte a scripts. Qualquer um pode criá-los e abrir acesso a eles, e qualquer um pode usá-los. Não há elemento central que controla o funcionamento da plataforma web.
- Os aplicativos na App Store da Apple têm aparência semelhante aos aplicativos da Web, mas são fornecidos e usados de maneiras completamente diferentes. Eles só podem ser baixados na App Store, portanto, a Apple tem o direito exclusivo de decidir o que os usuários podem instalar. Além disso, eles só podem ser executados em dispositivos iOS, ou seja, a Apple detém o monopólio da venda de dispositivos capazes de usar esses aplicativos. Os aplicativos na App Store são criados especificamente para o ambiente iOS, ou seja, os investimentos em sua criação são limitados apenas por esta plataforma. Para usar o aplicativo em qualquer outra plataforma, incluindo a Internet, ele deve ser reproduzido em um ambiente de desenvolvimento diferente e até em uma linguagem de programação diferente, o que significa: o lado do cliente do aplicativo deve ser recriado do zero.
Você pode aplicar esse modelo aos sistemas de API e à ideia de criar uma plataforma de API para aplicativos.
Às vezes, a plataforma da API se refere a um ambiente específico que fornece acesso à API. Logo, ele começa a se assemelhar levemente ao barramento de serviço corporativo tradicional, onde uma plataforma semelhante deve fornecer a infraestrutura e as APIs se tornam acessíveis devido ao fato de poderem usá-la.
Em outros casos, ao falar sobre a plataforma API, eles significam um conjunto comum de princípios usados e fornecidos pelos serviços. Nesse caso, se o serviço se tornar parte da plataforma, não terá nada a ver com onde e como o acesso é aberto a ela. Se os serviços seguirem os mesmos princípios, protocolos e modelos, eles fornecerão APIs nessa plataforma e, assim, se tornarão parte do sistema de API.
O segundo tipo de plataforma é mais abstrato, mas, ao mesmo tempo, possui mais recursos. Separar quais funções executam e como elas executam, facilita a contribuição dos usuários para a plataforma. Também abre muitos caminhos para a inovação, permitindo que os aplicativos experimentem métodos de implementação sem comprometer sua capacidade de contribuir para o sistema de API.
E, novamente, tome a Internet como exemplo. Se você olhar apenas do ponto de vista da API, ela poderá mudar muito com o tempo. Por exemplo, uma rede de entrega de conteúdo (CDN) não está integrada à própria Internet. Sua existência foi possível devido à complexidade do conteúdo da Internet e à flexibilidade do navegador, o que permite gerar páginas da Web com base em várias fontes obtidas, possivelmente de lugares diferentes. Pode-se argumentar que o potencial para criar uma CDN já existia nos princípios e protocolos das primeiras páginas da Web, mas o modelo da CDN apareceu apenas quando surgiu.
É essa capacidade de se adaptar às novas tarefas que é necessária nos sistemas de API. Projetamos um sistema baseado em princípios e protocolos abertos e extensíveis, mas podemos e queremos alterá-lo, se necessário. Também estamos criando modelos de suporte que ajudam os aplicativos a resolver problemas com mais eficiência e queremos desenvolver esses modelos com o tempo.
Princípios, protocolos e modelos
A principal conclusão da seção anterior: a plataforma não deve exigir uma maneira específica de fazer algo (responda à pergunta “Como?”) Ou um local específico (responda à pergunta “Onde?”). Uma boa plataforma é criada para o desenvolvimento contínuo da arquitetura, ou seja, a arquitetura da plataforma (e não apenas a arquitetura do produto) está em constante evolução, e nem tudo é desenvolvido de uma só vez, para que permaneça inalterado o tempo todo.
DESENVOLVIMENTO CONTÍNUO DA ARQUITETURA
O desenvolvimento contínuo da arquitetura é uma metodologia para o desenvolvimento contínuo dos fundamentos da arquitetura do produto. Produtos individuais são criados usando estruturas de arquitetura existentes, e os relatórios sobre a aplicação dessas estruturas podem melhorar a arquitetura do produto, tornando-a mais eficiente.
Uma metodologia de desenvolvimento flexível e o DevOps são dedicados a melhorar o desenvolvimento de produtos individuais. Eles não falam sobre como melhorar o básico desse processo para que uma arquitetura de sistema mais eficiente seja útil para a arquitetura do produto. O desenvolvimento contínuo ocorre quando produtos individuais são criados no ambiente de trabalho de um sistema existente. O sistema facilita a criação de novos produtos e ajuda o sistema a encontrar áreas para melhoria, criando assim um ciclo de feedback.
O desenvolvimento contínuo da arquitetura se concentra no desenvolvimento de uma estrutura que não prejudique os produtos existentes e permita a criação de combinações de produtos. , , .
, , . -. , . 30 , , , . ? , .
, , . , , , , . — , , , . — . , , , , , IT-, . .
- — , . — , (uniform resource identifier, URI), URI . , ( ) HTTP ( - , HTTPS), , . API, .
- , . (Hypertext Transfer Protocol (HTTP)), (FTP) , WebSockets WebRTC. , , HTTP/2.
- — . , , , . — Oauth, HTTP, — . — . , Oauth, , CDN. , , , , . — , .
, . , , . , -, .
, . . , - , . , , . , , , .
API . , , , , , . API — , , .
API
API . , , . , «» API, , API, .
API .
- API (, / ) . , API RPC — , API REST .
- API . , API HTTP HTTP.
- API . , 200 HTTP ( http://webconcepts.info/concepts/http-header/ ), . API , , .
- API , API ( «» . 188). : API , API, .
, — . , — . , , . , .
API — , .
- , , , , . , .
- , , . , . , , .
. , , , .
« » - - , . XML/JSON. XML-, API JSON ( , , , ).
API API
API , , , API . , . , API! API API: «, API, API».
, , API API (, , API). API API. API ( — «» « API» ), API . , .
, , , , . , API API.
, API API , . , .
. , API . , , - API.
«», «», «» «» . , , . , - , . , . , , , , , . « API» « API» 9 .
, API, API, API .
API , — , . . . — , .
, : , API, API. , , , , , , , API API, API API. API , , .
. , API, , , . , -, .
API API, , , , -. , : , API , , , , .
, API , : API , . : , , API, , .
— API, OAuth.io APIDays — API, . API API, , , API - . API, «API : », 2015 API « ». , - HEC API.
, API . IETF W3C. , , EMC, Siemens CA Technologies.
. API UX , API .
, , , , - . API API , , , API .
»
»
»
25% —
APIe-mail .