Categoria: Application Development

Application Development Cloud

Learn: Desenvolvendo (APIs) Application Programming Interface

Veja nesse artigo como desenvolver Application Programming Interface (APIs) e quais são os conceitos fundamentais relacionados com o desenvolvimento de APIs de boa qualidade.Em termos mais simples, podemos dizer que as APIs permitem que um software converse com outro software. Mas o que é API ao pé da letra?API significa “Application Programming Interface ou, em português, Interface de Programação de Aplicativos. Esta interface de programação é um conjunto de padrões de programação que permitem a construção de aplicativos e a sua utilização. API é um conceito relativamente amplo.Na maioria das vezes uma API se comunica com diversos outros códigos interligando diversas funções em um aplicativo. Um exemplo de uma API muito utilizada é a API dos sistemas operacionais que possuem diversos métodos e se comunicam com diversos processos do sistema operacional.Neste artigo, nós passaremos por conceitos fundamentais sobre APIS, como e porque criar uma API, a importância do versionamento, como podemos fazer uma boa API e como verificar a qualidade da API através de conceitos chaves como:- Compreensibilidade- Consistência- Descoberta- Facilidade em tarefas simples- e preservação de investimento.Porque criar uma APICom uma API podemos criar sistemas melhores e minimizar o entendimento deles.Através do reuso também podemos nos concentrar no mais importante: a lógica da aplicação. Desssa forma, podemos reutilizar frameworks e bibliotecas construídos por terceiros. Por exemplo, ninguém escreve um banco de dados do zero, pelo contrário, reutilizamos o que já existe e alteramos o código fonte para evoluir o código e ou adaptá-lo a alguma necessidade especial que temos em nosso projeto.Não é necessário saber tudo de uma API, basta que saibamos aquilo que atenda as nossas necessidades, para isso é sempre interessante possuirmos a documentação em mãos. A API minimiza o entendimento de todos os detalhes de um componente e assim serve como um “alicerce”.VersionamentoO sistema de numeração utilizado para sistemas de software é baseado em números naturais com um ponto os separando. Este ponto é necessário para acomodar “não linearidades” no desenvolvimento do software. Isso ocorre porque não existe uma direção única de desenvolvimento de um software, mas sim muitos ramos representando correções de bugs, correção de um bug que gerou outro bug, e assim por diante.Dessa forma, uma versão 1.1.1 significa que ela contém menos funcionalidades que uma versão 2.0 que foi lançada antes da versão 1.1.1.Abaixo um exemplo de um versionamento de software:Cada parte de uma aplicação modular tem um número de versão, geralmente um conjunto de números naturais separados por pontos, tal como “1.34.8”. quando uma nova versão é lançada, ela deve ter um novo e maior número de versão, como 1.34.10, 1.35.1 ou 2.0.A cada novo lançamento é importante mantermos todos os contratos que funcionavam nas versões anteriores funcionando nas novas também.Outra situação importante é nos mantermos informados das alterações nas dependências externas.Como fazer uma boa APIAlgumas pessoas pensam que as APIs são compostas apenas de classes, métodos e javadoc usado para documentá-los. O javadoc é uma importante ferramenta que fornece uma boa visibilidade da API, porém ainda assim uma API é um termo muito mais amplo do que essa visibilidade poderia indicar. Uma API inclui muitos outros tipos de interfaces.O exemplo mais óbvio e simples de uma API é um conjunto de classes, seus métodos e seus campos. Provavelmente se estivermos produzindo uma biblioteca em Java iremos empacotá-la num arquivo JAR contendo essas classes.Essas classes e seus membros se tornarão uma API da biblioteca.Uma situação muito importante de cuidarmos de uma API é a estrutura das informações de saída. a implementação padrão do toString() em objetos Java que imprime apenas nomes de classe e códigos objeto de hash hexadecimais não é muito útil.Para fins de depuração, muitas vezes substitui-se os métodos toString() para retornar informações mais significativas. Dessa forma, os objetos sempre devem trazer informações úteis. Caso contrário o cliente tentará traduzir as mensagens tentando encontrar algo significativo. Um exemplo disso e que foi concertado na API Java era a antiga Exception.printStackTrace (OutputStream). Não existia uma forma de entender a origem de uma exceção a não ser que pudéssemos traduzir esta saída. na versão Java 1.4 esse problema foi concertado através de um novo método getStackTrace() que retorna as mesmas informações porém num formato muito mais estruturado. Assim, não foi mais necessário uma análise e um parse na informação textual.Exemplos de APIS que usamos todos os dias:Pagamentos online (PayPal, Cielo, PagSeguro, Moip)APIs permitem executar pagamentos e transferências sem sair do site da loja, ou fornecedor do serviço.Dessa forma, usando as APIs das carteiras digitais, o comprador não precisa colocar os dados do cartão de crédito no site da loja, e sim, apenas seu usuário e senha do PayPal, autorizando a compra.As informações já ficam armazenadas com o provedor de pagamento. Muito mais prático!Oferecer soluções de pagamentos confiáveis dentro da loja combate a resistência do cliente, que muitas vezes tem receios de ter sua segurança de dados comprometida e despesas indevidamente geradas no seu nome por cartões clonados, por exemplo.O resultado? Melhores taxas de conversão e clientes mais seguros e satisfeitos!Localização (Google Maps, Foursquare)Através da integração das APIs, é possível criar aplicativos próprios baseados na localização da sua empresa ou que reagem à posição do seu usuário!Elas permitem ainda visualizar dados sobre topografia e geografia e ajudam a determinar previsões de clima.Uma ideia genial é a do aplicativo Zombies, Run!, que se conecta ao GPS do celular (através de uma API do sistema) para traçar sua rota de corrida no Maps, unindo exercício físico a um jogo de sobrevivência (e fuga) em um apocalipse zumbi.Muito criativo!Também é comum que serviços como o Google Maps se conectem a outras APIs, como as de empresas de transporte urbano, para determinar rotas de horários.Uma API, que consulta outra e mais outra API!Curiosidade: você sabia que a API do Google Maps começou a ser usada com engenharia reversa? Logo após o serviço ser lançado, alguns desenvolvedores tiveram várias ideias de aplicações e exploraram o código para colocar suas ideias em prática.Estamos vivendo a nova Economia das APIs e é preciso se adaptar aos tempos. Empresas sem uma estratégia nesta área correm o risco de ficar para trás!Para o usuário final, as APIs podem passar despercebidas mas, para o seu negócio, jamais.Fontes: blog aws / devmedia

LER MAIS ARTIGOS

Siga os canais da Kumulus nas redes sociais:

Facebook

Instagram

Youtube

Envelope

Application Development Cloud DevOps

Aprenda sobre os 05 pilares da qualidade de software: qualidade, disponibilidade…

Aprenda sobre os 05 pilares da qualidade de software
Um aplicativo em nuvem que funciona de forma satisfatória se concentrará nesses cinco pilares da qualidade do software: qualidade, disponibilidade, resiliência, gerenciamento e segurança. São eles:

Escalabilidade: A capacidade de um sistema para lidar com aumento de carga.
Disponibilidade: A proporção de tempo que um sistema está funcional e funcionando.
Resiliência: A capacidade de um sistema para recuperar-se de falhas e continuar a funcionar.
Gestão: Processos de operações que mantém um sistema em execução na produção.
Segurança: Protegendo aplicativos e dados contra ameaças.
Escalabilidade
Escalabilidade é a capacidade de um sistema para lidar com aumento de carga. Existem duas maneiras principais que um aplicativo pode escalar. Escala vertical (aumento de escala) significa aumentar a capacidade de um recurso, por exemplo, usando um tamanho de VM maior. Escala horizontal (escalando fora) é a adição de novas instâncias de um recurso, como VMs ou réplicas de banco de dados.

A escala de nuvem real. Os aplicativos podem ser projetados para serem executados em centenas ou até milhares de nodes, alcançando escalas que não são possíveis em um único node.
Escala horizontal é elástica. Você pode adicionar mais instâncias se a carga aumentar ou removê-las durante períodos mais silenciosos.
O dimensionamento pode ser disparado automaticamente, seja em uma programação ou em resposta a alterações na carga.
A expansão pode ser mais barata do que a ampliação. Executar várias VMs pequenas pode custar menos que uma única grande VM.
O dimensionamento horizontal também pode melhorar a resiliência, adicionando redundância.

Se uma instância ficar inativa, o aplicativo continuará em execução.

Uma vantagem do dimensionamento vertical é que você pode fazer isso sem fazer alterações no aplicativo. Mas em algum momento você atingirá um limite, onde você não poderá mais escalar. Nesse ponto, qualquer escala adicional deve ser horizontal.

A escala horizontal deve ser projetada no sistema. Por exemplo, você pode dimensionar VMs colocando-as atrás de um load balancer. Mas cada VM no pool deve ser capaz de manipular qualquer solicitação do cliente, portanto, o aplicativo deve estar sem estado ou armazenar o estado externamente (digamos, em um cache distribuído). Os serviços de PaaS gerenciados geralmente têm dimensionamento horizontal e escalonamento automático integrados. A facilidade de escalonar esses serviços é uma grande vantagem do uso de serviços de PaaS.

Apenas adicionar mais instâncias não significa que um aplicativo será dimensionado, no entanto. Pode simplesmente empurrar o gargalo em algum outro lugar. Por exemplo, se você dimensionar um front-end da Web para lidar com mais solicitações de clientes, isso poderá acionar as contenções de bloqueio no banco de dados.

Sempre realize testes de desempenho e carga para encontrar esses possíveis gargalos. As partes com estado de um sistema, como banco de dados, são a causa mais comum de gargalos e exigem um projeto cuidadoso para dimensionar horizontalmente. Resolver um gargalo pode revelar outros gargalos em outros lugares.

Use a lista de verificação Escalabilidade para revisar seu design do ponto de vista da escalabilidade.
Disponibilidade
A disponibilidade é a proporção de tempo em que um sistema está funcional e funcionando. Geralmente é medido como uma porcentagem do tempo de atividade. Erros de aplicação, problemas de infraestrutura e carga do sistema podem reduzir a disponibilidade.

Um aplicativo de nuvem deve ter um Objetivo de Nível de Serviço (SLO) que defina claramente a disponibilidade esperada e como a disponibilidade é medida. Ao definir a disponibilidade, observe o caminho crítico. O front-end da Web pode ser capaz de atender a solicitações de clientes, mas se toda transação falhar porque não pode se conectar ao banco de dados, o aplicativo não estará disponível para os usuários.

A disponibilidade é geralmente descrita em termos de “9s” – por exemplo, “quatro 9s” significa 99,99% de tempo de atividade. A tabela a seguir mostra o possível tempo de inatividade cumulativo em diferentes níveis de disponibilidade.

% Tempo de atividade
Tempo de inatividade por semana
Tempo de inatividade por mês
Tempo de inatividade por ano

99%
1,68 horas
7,2 horas
3,65 dias

99,9%
10 minutos
43,2 minutos
8,76 horas

99,95%
5 minutos
21,6 minutos
4,38 horas

99,99%
1 minuto
4,32 minutos
52,56 minutos

99,999%
6 segundos
26 segundos
5,26 minutos

Observe que 99% de tempo de atividade pode resultar em uma interrupção de serviço de quase duas horas por semana. Para muitas aplicações, especialmente aplicações voltadas ao consumidor, isso não é um SLO aceitável.

Para muitas aplicações, especialmente aplicações voltadas ao consumidor, isso não é um SLO aceitável. Por outro lado, cinco 9s (99,999%) significam não mais do que 5 minutos de inatividade em um ano. É desafiador o suficiente apenas detectar uma interrupção tão rápida, quando mais resolver o problema. Para obter uma disponibilidade muito alta (99,99% ou mais), você não pode confiar na intervenção manual para se recuperar de falhas. A aplicação deve ser self-diagnosing e self-healing, que é onde a resiliência se torna crucial.

No Azure, o Acordo de Nível de Serviço (SLA) descreve os compromissos da Microsoft quanto a tempo de atividade e conectividade. Se o SLA de um determinado serviço for 99,5% isso significa que você deve esperar que o serviço esteja disponível 99,95% do tempo.

Os aplicativos geralmente dependem de vários serviços. Em geral, a probabilidade de um dos serviços ter tempo de inatividade é independente. Por exemplo, suponha que seu aplicativo dependa de dois serviços, cada um com um SLA de 99,9%. O SLA composto para ambos os serviços é de 99,9% x 99,9% ≈ 99,8% ou um pouco menos do que cada serviço por si só.

Use a lista de verificação de disponibilidade para revisar seu design de um ponto de vista de disponibilidade.
Resiliência
Resiliência é a capacidade do sistema de se recuperar de falhas e continuar a funcionar. O objetivo da resiliência é retornar o aplicativo a um estado totalmente funcional após uma falha ocorrer. A resiliência está intimamente relacionada à disponibilidade.

No desenvolvimento tradicional de aplicativos, houve um foco na redução do tempo médio entre falhas (MTBF). Esforço foi gasto tentando evitar que o sistema falhasse. Na computação em nuvem, é necessária uma mentalidade diferente, devido a vários fatores:

Os sistemas distribuídos são complexos, e uma falha em um ponto pode potencialmente se espalhar pelo sistema.
Custos para ambientes de nuvem são mantidos baixos através do uso de hardware commodity, portanto, falhas ocasionais de hardware devem ser esperadas.
Os aplicativos geralmente dependem de serviços externos, que podem ficar temporariamente indisponíveis ou limitar os usuários de alto volume.
Os usuários de hoje esperam que um aplicativo esteja disponível 24 horas por dia, 7 dias por semana, sem nunca ficar off-line.

Todos esses fatores significam em nuvem devem ser projetados para esperarem falhas ocasionais e se recuperarem deles. O Azure tem muitos recursos de resiliência já incorporados à plataforma. Por exemplo:

O armazenamento do Azure, o banco de dados SQL e o banco de dados do Cosmos fornecem replicação de dados incorporada, tanto em uma região quanto entre regiões.
Os discos gerenciados do Azure são colocados automaticamente em diferentes unidades de escala de armazenamento para limitar os efeitos de falhas e hardware.
VMs em um conjunto de disponibilidade estão espalhadas por vários domínios de falha. Um domínio de falha é um grupo de VMs que compartilham uma fonte de energia e um comutador de rede comuns. A disseminação de VMs em domínios de falha limita o impacto de falhas físicas de hardware, interrupções de rede ou interrupções de energia.

Dito isso, você ainda precisa criar resiliência em seu aplicativo. As estratégias de resiliência podem ser aplicadas a todos os níveis da arquitetura. Algumas atenuações são mais táticas por natureza – por exemplo, tentar novamente uma chamada remota após uma falha de rede transitória. Outras atenuações são mais estratégias, como o failover de todo o aplicativo para uma região secundária.

Mitigações táticas podem fazer uma grande diferença. Embora seja raro que uma região inteira sofra uma interrupção, problemas transitórios, como congestionamento da rede, são mais comuns – portanto, direcione-os primeiro. Ter o monitoramento e o diagnóstico corretos também é importante, tanto para detectar falhas quando elas ocorrem quanto para encontrar as causas-raiz.

Ao projetar um aplicativo para ser resiliente, você deve entender seus requisitos de disponibilidade. Quanto tempo de inatividade é aceitável? Isso é parcialmente uma função do custo. Quanto o tempo de inatividade potencial custará à sua empresa? Quanto você deve investir para tornar o aplicativo altamente disponível?

Use a lista de verificação Resiliency para revisar seu design do ponto de vista de resiliência.
Gestão do DevOps
Este pilar cobre os processos de operações que mantêm um aplicativo em execução na produção.

As implantações devem ser confiáveis e previsíveis. Eles devem ser automatizados para reduzir a chance de erro humano. Eles devem ser um processo rápido e rotineiro, para que não atrasem o lançamento de novos recursos ou correções de bugs. Igualmente importante, você deve poder retroceder ou avançar rapidamente se uma atualização tiver problemas.

Monitoramento e diagnóstico são cruciais. Os aplicativos em nuvem são executados em um datacenter remoto, no qual você não tem controle total da infraestrutura ou, em algum casos, do sistema operacional. Em um aplicativo grande, não é prático fazer login em VMs para solucionar um problema ou filtrar arquivos de log. Com os serviços de PaaS, talvez nem haja uma VM dedicada para fazer o login. O monitoramento do diagnóstico fornecem informações sobre o sistema, para que você saiba quando e onde as falhas ocorrem. Todos os sistemas devem ser observáveis. Use um esquema de log comum e consistente que permita correlacionar eventos entre sistemas.

O processo de monitoramento e diagnóstico tem várias fases distintas:

Instrumentação. Gerando os dados brutos, de logs do aplicativo, logs do servidor da web, diagnósticos incorporados na plataforma do Azure e outras fontes.
Coleta e armazenamento. Consolidando os dados em um só lugar.
Análise e diagnóstico. Para solucionar problemas e ver a integridade geral.
Visualização de alertas. Usando dados de telemetria para detectar tendências ou alertar a equipe de operações.

Use a lista de verificação do DevOps para revisar seu design de um ponto de vista de gerenciamento e DevOps.
Segurança
Você deve pensar em segurança durante todo o ciclo de vida de um aplicativo, desde o design e a implementação até a implantação e as operações. A plataforma do Azure fornece proteções contra uma variedade de ameaças, como invasão de rede e ataques DDoS. Mas você ainda precisa criar segurança em seu aplicativo e em seus processos de DevOps.
Segurança de aplicativos
Em geral, as práticas recomendadas de segurança para desenvolvimento de aplicativos ainda se aplicam à nuvem. Isso inclui coisas como o uso de SSL em todos os lugares, proteção contra ataques de CSRF e XSS, prevenção de ataques de injeção de SQL e assim por diante.

Fonte: Microsoft

Social media & sharing icons powered by UltimatelySocial