Aprenda as me…

Read more

Read more

Read more

Read more

Read more

Read more

Read more

Read more

Antes de qualquer coisa, é preciso esclarecer alguns termos usados dentro do universo REST, que serão utilizados constantemente neste texto. São significados que podem divergir dependendo do contexto. 

Recursos: são as entidades que a API pode gerenciar (ex: usuário e empresa). 

URI (Uniform Resource Identifier): é o identificador do recurso, que deve ser único. 

Endpoint: de forma simplificada, é o que vem após o URN. Um exemplo hipotético: para adicionar uma empresa no banco de dados, é feita uma requisição POST à API no URL https://site.com/api/empresas e segue a seguinte lógica no universo REST: 

Métodos: são os métodos de requisição HTTP, também conhecidos como HTTP Verbs (verbos HTTP). 

Neste artigo, você vai encontrar convenções usadas durante a construção de uma API que podem torná-la mais segura e consistente. 

Utilizando HTTP do jeito certo

Uma requisição HTTP pode ser realizada com base em alguns métodos. Dentre os mais utilizados estão: (GET, PUT, POST e DELETE). É comum dar o nome do recurso aos endpoints e utilizar os métodos para diferenciar a função do endpoint em questão. 

Exemplos de gerenciamento do recurso empresa: 

GET /empresas: solicita todas as empresas cadastradas; 

POST /empresas: efetua cadastro de uma nova empresa; 

PUT /empresas: atualiza informações de uma empresa com base em um identificador passado na requisição; 

DELETE /empresas: deleta uma empresa do banco de dados com base em um identificador passado na requisição. 

Note que não foi criado um URI diferente para cada ação da API como criarEmpresa ou deletarEmpresa. A API foi configurada para ter o mesmo endpoint para todas as funções e diferenciá-las apenas pelo método da requisição. 

Sobre o uso de plurais - É uma convenção utilizar o plural nos URIs para disponibilizar o recurso em questão. Exemplo: /empresas ao invés de /empresa. 

Um ponto importante que vale ressaltar é que o método GET não deve ser utilizado para efetuar alterações nos dados armazenados, como adicionar, atualizar ou deletar. Utilize os demais métodos para estas ações. 

Padronização e tratamento de erros

Trate as mensagens para evitar o retorno de erros internos da aplicação ao usuário final e procure sempre detalhá-los e evitar mensagens genéricas. 

Por exemplo: você está inserindo um novo usuário em um banco de dados MySQL e foi retornado um erro específico do banco. Ao invés de devolver a requisição com a mensagem original do erro, trate-a para se tornar mais amigável e evitar revelar informações sensíveis sobre o banco. 

Quanto ao detalhamento do erro, seja o mais específico possível. No lugar de devolver uma mensagem simples como “Não foi possível cadastrar o usuário”, deixe o motivo o mais claro possível, como “O e-mail informado já está cadastrado”. 

Procure padronizar as mensagens de erro, utilizando sempre o mesmo idioma e linguagem. Ao responder à chamada com um erro, utilize os cabeçalhos HTTP para identificar o tipo do erro retornado. 

4xx- Client error: um erro cujo código inicia-se com o número 4 indica que o erro foi causado por alguma falha por parte do client. Dentre os principais, estão inclusos: 

400 Bad Request: o servidor não entendeu o que o client está solicitando. 

401 Unauthorized: o client não está autenticado e não tem autorização para acessar o endpoint. 

403 Forbidden: o client está autenticado e a requisição é válida, porém não tem permissão de acesso àquele endpoint. 

404 Not Found: o endpoint não foi localizado.

5xx- Server error: um erro cujo código inicia-se com o número 5 indica que foi causado por alguma falha por parte do servidor. Dentre os principais, estão inclusos: 

500 Internal Server Error: o servidor não conseguiu lidar com o erro. 

503 Service Unavailable: o servidor está indisponível para responder a requisição, onde a causa mais comum é sobrecarga. 

504 Gateway Timeout: o tempo de resposta expirou e o servidor não conseguiu responder a tempo. 

Filtragem

Procure adicionar filtros nas chamadas a fim de reduzir a largura da banda de dados transportados, tempo de processamento e de resposta do servidor, assim reduzindo custos desnecessários e contribuindo com a disponibilidade do serviço. 

Procure também utilizar sub recursos para as relações durante as consultas e filtros. Por exemplo: para resgatar os empregados de uma determinada empresa, construa um endpoint semelhante a:

Segurança

Utilize um sistema de autenticação para restringir o acesso à API, seja por meio de usuários autenticados por um token criptografado ou qualquer outra forma considerada segura. 

Uma camada a mais de segurança é a configuração do CORS (Cross-Origin Resource Sharing) para evitar que URLs não autorizados façam requisição à API. 

Faça validação e tratamento nos inputs, para evitar a injeção de scripts na aplicação que possam comprometer sua integridade. 

Conclusão

Suas APIs tem mais chances de cumprirem a missão e deixar seus clientes satisfeitos se você aplicar cuidados simples, como os descritos acima.  

Boas práticas como estas podem ser uma parte do que transformará a forma como as empresas enxergam você, de um programador comum, a alguém que se preocupa com uma entrega de qualidade. 

Quer conversar sobre DX e APIs? Clique aqui e marque uma reunião.

Este artigo foi escrito por Henry Kimura e publicado originalmente em Prensa.li.

Se você trabalha na área de tecnologia provavelmente já ouviu falar do termo SDK, especialmente na hora de discutir sobre produtos e serviços com a equipe de desenvolvimento de software. No entanto, você sabe exatamente o que é e quão importante é um SDK?

A maioria dos aplicativos móveis faz uso de APIs (interfaces de programação de aplicativos) para aprimorar os recursos do aplicativo, adicionar recursos exclusivos ao aplicativo e melhorar a padronização do aplicativo.

Sem eles, os desenvolvedores achariam um desafio implantar aplicativos de alto desempenho com recursos limitados. Mas outra tecnologia utilizada para esse mesmo fim é o SDK.

Afinal o que é um SDK?

Trata-se de uma abreviação para Software Developer Kit, ou seja, um Kit de Desenvolvimento de Software. Ele deve incluir todas as informações e ferramentas necessárias para a criação de uma aplicação específica.

O ideal é que SDKs contenham documentação relevante, bibliotecas, exemplos de códigos, explicação dos processos, guias para desenvolvedores usarem e integrarem em seus próprios aplicativos. Todos esses recursos visam uma redução da complexidades do desenvolvimento de programas e aplicativos.

Logo um bom SDK:

• É fácil de usar por outros desenvolvedores;

• Apresenta documentação completa;

• Possui funcionalidades que agreguem valor;

• Não afeta negativamente o consumo de CPU, bateria ou dados de um dispositivo móvel.

E a relação de SDKs com APIs?

Existe uma relação muito importante entre SDKs e APIs. Eles garantem que a API fornecida seja implementada corretamente, reduzindo o esforço do desenvolvedor quanto à implementação de APIs. Há vezes em que o SDK oferece até recursos aprimorados em cima de APIs, o que representa uma melhora na User Experience.

Além disso SDKs auxiliam em uma atualização mais fácil e no manuseio de deprecações para determinadas APIs de nível inferior.

Os métodos, sistemas e integrações da API não estão somente presentes no SDK, como também estão explicados e demonstrados — dessa maneira, o SDK consegue oferecer não só um conjunto de ferramentas para criação, mas também um canal de comunicação direto, customizável e gerido pelo provedor da API.

Geradores de SDKs

Mesmo que não seja obrigatória a associação entre APIs e SDKs, estes podem ser muito úteis por conta de suas bibliotecas, estruturas, documentação e diretrizes, oferecendo melhor suporte às APIs.

Pensando na questão da experiência do usuário final, os SDKs são grandes pontos de contato com as pessoas, o que significa que desenvolver um SDK adequado pode gerar um impacto positivo quanto ao sucesso de uma API.

A questão envolvendo SDKs criados manualmente é o tempo e esforço necessário por parte do time de desenvolvimento. Uma solução para isso é gerar automaticamente SDKs tendo como base a de uma especificação de API.

Como gerar automaticamente um SDK

Geradores de código viabilizam a geração automática de SDKs. A ideia é utilizar uma Especificação de API como fonte para derivar SDKs funcionais mais rapidamente.

Um exemplo é o APIMatic CodeGen Engine, que aceita especificações de APIs em diferentes formatos como Swagger / OpenAPI, RAML e API Blueprint, oferecendo assim SDKs funcionais e completos, contendo:

• Bibliotecas cliente;

• Amostras de código dinâmico;

• Documentação;

• Guias de primeiros passos.

Mas será que a geração automática de SDK é para todos?

Os SDKs ajudam no aumento da adoção de APIs, possibilitando que desenvolvedores, de diferentes plataformas ou linguagens consigam iniciar o uso da API rapidamente. Poder contar com um gerador de SDK facilita a integração especialmente quando o time é reduzido e não existe a oportunidade de produzir o seu próprio SDK.

Apesar dos custos reduzidos e de ferramentas de geração de código serem um boa solução se você precisa de SDKs para suas APIs, é necessário analisar o cenário, para concluir se é mais sensato escrever SDKs manualmente ou mesmo uma combinação de ambos.

Por exemplo, quando você planeja inserir uma alguma lógica específica de negócio em seus SDKs a fim de facilitar o design da API ou para para explorar o processamento do lado do cliente e otimizar a escalabilidade da API.

De certa forma, é possível contornar isso a partir de uma abstração HTTP e ganchos de solicitação antes e depois no SDK, possibilitando que os wrappers sejam gravados sobre o código gerado. O mais adequado, no fim das contas é que o provedor da API decidase determinadas medidas são suficientes para seu caso de uso específico.

O mercado de Mobile SDK

Por meio de SDKs desenvolvedores conseguem integrar serviços externos em seus aplicativos com maior facilidade, o que representa uma economia significativa de tempo e dinheiro em um projeto. Logo, ao usar SDKs devs tem em mãos atalhos de programação, já que não precisam se preocupar com funcionalidades que estão prontas e foram criadas por terceiros.

Atualmente o mercado de SDKs apresenta variadas oportunidades, sendo fácil encontrar um bom devkit para as funções necessárias de determinado aplicativo. Alguns exemplos existentes são de Crash Reporting (relatório de bugs), de Engagement (retenção e engajamento de usuários) e de Advertising (auxílio financeiro com exibição de anúncios). 

Dentre os existentes o SDK do Facebook é um dos mais utilizados. Ele fornece a maneira fácil de acompanhar o desempenho dos anúncios de aplicativos, implementar o compartilhamento na rede, permitir que as pessoas acessem um aplicativo com o Facebook, criar bots e integrar outras funcionalidades.

Entre outras ferramentas, esse SDK provê dados anônimas do público sobre as pessoas que interagem com o aplicativo. O Facebook também contém cinco SDKs de componentes que podem ser conectados individualmente.

Outra SDK amplamente utilizada, no caso de dispositivos móveis Android é o SDK de Google Analytics. Ele fornece dados sobre uso de aplicativos, o envolvimento do usuário e a atribuição entre redes. É integrado nativamente ao Firebase, a plataforma de desenvolvedores de aplicativos do Google e fornece relatórios ilimitados para até 500 eventos distintos.

Benefícios do SDK no desenvolvimento e uso de aplicações

Se você está pensando em integrar um SDK ao um aplicativo, vale mencionar alguns impactos positivos no seu negócio

• Integração simplificada com menos custos

Através de funcionalidade já definidas do SDK, o processo de integração se torna mais simples. Além disso, os SDKs proporcionam todo o suporte e instruções necessárias para que sua equipe de desenvolvimento possa integrá-los sem grandes complicações. 

• Maior confiabilidade e segurança

Os SDKs permitem que o desenvolvedor deixe as features de segurança nas mãos de empresas com experiência e conhecimento consolidado no assunto. Ainda sim, é preciso pesquisar muito bem a respeito da reputação da empresa desenvolvedora e questionar sobre a estabilidade e os níveis de segurança do SDK desejado.

• Produtos lançados em menos tempo

A integração com SDKs permite que as empresas façam uso de funcionalidades desenvolvidas por terceiros e por isso não precisam lidar com processos muito complexos. A baixa complexidade e burocracia acaba interferindo positivamente no tempo de lançamento de uma aplicação.

Alguns cuidados

Como você pode ver, integrar um SDK a um aplicativo pode trazer vantagens aos negócios, porém é importante ter em mente o conhecimento aprofundado dos aspectos técnicos de tais kits antes de adicioná-los a um app. 

A seguir alguns dos critérios que os desenvolvedores precisam ficar atentos:

1. Compatibilidade

É importante sempre verificar a compatibilidade do seu SDK com a arquitetura mais recentes do sistema operacional. Por isso, acompanhe as diretrizes impostas pelas versões mais novas do SO e teste seus SDKs.

Quando se está criando um SDK pela primeira vez, você deve definir uma versão base do sistema operacional compatível com o SDK e verificar se as futuras versões do SDK conseguirão dar suporte a primeira versão com a qual você começou.

2. Recursos

Na criação de SDKs, especialmente os voltados para mobiles, o desenvolvedor precisa ter em mente quais recursos seu SDK irá utilizar/consumir. Ao atender aos requisitos, um SDK deve fazer isso mantendo os recursos mínimos e fornecendo a funcionalidade máxima.

Para isso, os seguintes fatores apresentam papel fundamental:

• Bateria: Procure evitar ações que esgotem a bateria do usuário final tais quais pesquisa persistente de rede, processamento intensivo em segundo plano ou solicitação frequente de atualizações de localização. Por isso, preste atenção ao estado de energia do dispositivo, por exemplo, verificando se dispositivo está no modo de baixa. Opte por usar instrumentos como “Diagnóstico de energia” para verificar o consumo da bateria.

• Memória: o SDK deve obter alocações quando necessário, mas liberar memória após a conclusão da tarefa. Um vazamento de memória no SDK normalmente recebe feedback negativo. Logo, execute instrumentos para alocação e vazamentos de memória e teste regularmente.

• Desempenho: enviar um SDK para desenvolvedores sem antes realizar uma verificação de desempenho acarreta em risco. Execute testes de desempenho e testes de unidade oportunos, tendo como meta um mobile SDK que não afete o aplicativo host durante uso do seu SDK.

• Uso da rede: é importante que as solicitações sejam regradas, afinal de contas, nem todos os usuários finais possuem planos de dados ilimitados e também não há garantia sobre a qualidade da rede.

• Tamanho do kit: O tamanho de um SDK não é se resume ao tamanho do arquivo .aar ou .framework. Para chegar a uma estimativa mais realista, é necessário comparar o tamanho do arquivo de aplicativos de host de amostra .apk ou .ipa antes e depois de integrar o SDK. Além disso, outros fatores devem ser levados em conta como arquiteturas necessárias e dependências externas.

Melhores Práticas para criar um SDK

Com o pensamento de melhorar a área de atuação do desenvolvedor, quais são as melhores práticas para a criação de uma SDK?

• Simplicidade

Um SDK somente tem utilidade quando o usuário consegue compreendê-lo. Códigos muito complexos, implementações arcaicas podem desestimular o uso de um SDK. Por isso, é necessário que você garanta simplicidade em todas as etapas de criação.

Umas das maneiras que evitar tais situações é priorizar em um primeiro momento classes e métodos comumente mais utilizados. Assim o SDK mostra as funções utilizadas pelo usuários sem ofuscar as outras opções com métodos/funções que não serão usados

Simplicidade envolve forma e função. Ter isso em mente resultará em um SDK simplificado.

• Mapeamento de Endpoints

SDKs podem ser comparados a roadmaps, pois ao criar um SDK você está garantindo a corretude do seu mapeamento. Os endpoints devem ser mapeados no seu SDK assim como nas APIs. Isso facilitará a utilização do SDK

Realizar um mapeamento de endpoints implica em:

1. Atualizações contínuas do SDK;

2. Funções mapeadas e nomeadas adequadamente - o uso de nomeações consistentes além de ajudar na utilização do SDK, torna a comunicação mais clara;

3. Novas funcionalidades imediatamente adicionadas e definidas junto ao SDK e a documentação - no caso de classe ocultas, estas devem existir simplesmente por motivos de segurança, não porque foi esquecida.

• Usabilidade

A função de um SDK é seu maior valor, logo assegurar sua usabilidade é imprescindível. Uma boa maneira de introduzir um SDK e todas as suas peculiaridades é elaborando um modelo de Getting Started. Ele deve ser estruturado de forma que desenvolvedores já familiarizados com a linguagem e a função do código que representa o SDK, seja capaz de usá-lo em até 10 minutos.

Outro ponto é garantir que um bom volume de usuários possa usar seu serviço, por exemplo, oferecendo o codebase da API em diferentes linguagens. Porém, é preciso oferecer suporte correto de tais integrações.

Dois grandes aspectos

As vantagens de um SDK bem elaborado são evidentes. Experiência aprimorada do desenvolvedor, integração mais rápida e implementação de novos recursos, o que acaba levando a uma maior adoção do seu produto.

Por isso, na hora de criar ou optar por um SDK para integrar a um aplicativo, por exemplo, é preciso levar dois aspectos principais: dados e segurança. Você deve garantir que o SDK não tenha apenas alta velocidade, mas também proteja seus dados e informações. No caso de Mobile SDK, este deve valorizar soluções móveis opt-in e baseadas em permissão.

Como você pode ver, um SDK representa uma série de vantagens, dentre elas redução de esforços quanto as APIs. Quer ler outros artigos relacionados ao Ecossistema de APIs e Transformação Digital? Confira então o perfil da API Playbook na plataforma Prensa.

Quer conversar sobre DX e APIs? Clique aqui e marque uma reunião.

Este artigo foi escrito por David Ruiz e publicado originalmente em Prensa.li.

É cada vez mais comum que sites e aplicativos incorporem serviços terceirizados para estender e criar novas funcionalidades, muitos deles atualmente envolvem APIs. Qualquer serviço terceirizado, especialmente os dependentes dessas interfaces, precisa ser testado e monitorado frequentemente.

Há diversos fatores que podem ocasionar no mau funcionamento da API como:

• Pontos de extremidade da API com tempo de inatividade;

• Bugs na integração;

• Lentidão para autenticar API;

• API pouco robusta, ou seja, não consegue lidar com picos nas solicitações de entrada ou nas respostas de saída;

• Latência nas chamadas de API, adicionando e criando gargalos de desempenho.

A maioria dos problemas acima apresenta uma solução específica, entretanto melhor que buscar a solução de um problema é saber se prevenir contra ele. A maneira mais eficiente de evitar dores de cabeça com estes empecilhos é por meio de testes e monitoramento das APIs.

A realização desses testes é um item prioritário para que você tenha sucesso com suas APIs. É por meio deles que se verifica o funcionamento, o desempenho e a confiabilidade de diversos aplicativos e sistemas que utilizam suas APIs nas suas comunicações. 

Além disso, quando falamos de ciclo de vida de APIs é importante ter mente tais testes. As APIs não apenas agregam valor a um aplicativo, mas também aceleram os processos de negócios. Caso sua API não funcione como planejado ou sua eficácia seja questionável, dificilmente outras empresas ou desenvolvedores se interessarão por ela, mesmo que ela seja gratuita.

No caso de um e-commerce, por exemplo, se API do gateway de pagamentos não for capaz de verificar corretamente os dados do cartão do usuário, se sua integração com as opções de pagamento no site estiver quebrada, há risco de carrinhos abandonados, além de uma péssima User Experience. Se o site em questão também utilizar APIs para automatizar o gerenciamento de inventário, um desempenho ruim da API pode gerar atrasos no atendimento de pedidos, afetando as receitas do site.

Provedores de APIs devem levar em consideração em sua estratégia de monitoramento:

• Disponibilidade: as APIs devem apresentar funcionamento a qualquer hora do dia, a falta de disponibilidade afeta o desempenho do aplicativo e o usuário final.

• Segurança: monitorar uma API significa testar a confiabilidade desta em suas transações, a troca de dados de ser feita de forma segura e sem bots de extração de dados.

• Benchmarking: os dados coletados pela ferramenta de monitoramento devem ser abrangentes e fáceis de analisar, para que assim eles ajudem a comparar o desempenho da sua API com a dos concorrentes 

• SLA: A ferramenta de monitoramento alertará em casos de degradação ou interrupção do desempenho da API.

No caso de aplicativos que consomem várias APIs é vital manter uma constância nos monitoramentos. Cada integração de API deve ser testada regularmente quanto aos gargalos de desempenho.

Com relação aos testes de APIs, o desenvolvedor deve se manter atento às seguintes questões:

• A API funciona como esperado?

• Ela é capaz de lidar com grande volume de chamadas?

• Requisitos de segurança como autenticação, permissões de acesso e controle foram definidos pela API?

• A API leva a resultados consistentes?

• A interface é fácil de usar? Ela se integra bem a outras plataformas e aplicativos?

• A API disponibiliza documentação adequada para a realização dos testes?

Como funcionam os testes de API?

Testar uma API pode representar uma parte desafiadora dos testes de qualidade de software e de aplicativos, isso porque sua estrutura pode ser complexa e na maioria das vezes elas se baseiam em protocolos e padrões que comumente não são encontrados em outros tipos de teste.

De maneira resumida, testar uma API significa fazer solicitações para o endpoint desta e então validar sua resposta. Com isso é possível determinar se a API atende ou não as expectativas quanto a segurança e funcionalidade por exemplo.

Ao trabalhar com testes de APIs há uma série de validações que devem ser consideradas. Elas são:

• Validação do status retornado;

• Validação do header de retorno;

• Validação do body de response;

• Validação do comportamento da API quando o serviço está indisponível;

• Validação do comportamento da API ao enviar um JSON/XML com estrutura incorreta.

A seguir explicarei algumas das práticas mais eficientes quando o assunto é teste de APIs:

1. Documente todos requisitos de teste

Antes que você crie casos de testes de APIs, é preciso compreender os seguintes detalhes:

• objetivo da API

• workflow do aplicativo

• integrações suportadas pela API

• recursos e funções da API

Saber documentar tais requisitos é fundamental para a implementação da API. Isso auxiliará a planejar melhor todo o processo de testes.

2. Dê atenção às pequenas funções da API

Optar por escrever os casos de testes maiores, pulando os que são menores não é a melhor tática no caso de testes de APIs, já que através das pequenas funções de API é possível escrever pequenos códigos de teste e assim analisar se o resultado foi ou não o esperado.

3. Execute testes automatizados

Gradualmente testes manuais vem dando lugar aos automatizados, isso ocorre porque automatizar esse processo permite que a execução das chamadas de API seja mais eficiente, clara e com mais foco. Por isso saiba investir em ferramentas que automatizem os testes de sua API.

4. Realize agendamento diário dos testes

Uma ótima medida ao longo do processo de testes é agendar verificações diárias. Portanto, os testes de API devem ser planejados com antecedência, sendo isso apenas possível graças às ferramentas de teste de API automatizadas que vêm com recursos como:

• Comandos de testes incorporados;

• Ferramentas de gestão de testes;

• Ferramentas de rastreamento de defeitos;

• Geração de relatórios de log visuais.

Diariamente, quando você acessar o sistema poderá ver os resultados de tais testes e comprovar se os resultados estão os não dentro do esperado. Se os testes falharem basta verificar as saídas e validar os erros. 

5. Priorize a segurança

Testes de segurança de uma API não devem ser de forma alguma deixados de lado ou subestimados. O que acontece algumas vezes é o caso de desenvolvedores ignorarem a implementação de restrições de segurança da interface. Quando bem executados e com regularidade os testes podem garantir que sua API seja o mais segura possível durante seu ciclo de vida.

Um erro em um único aplicativo irá afetar apenas ele, no entanto quando o erro ocorre em uma API utilizada, isso afetará todos os aplicativos que dependem dela. Dessa forma inclua cenários de segurança em seus testes para averiguar questões relacionadas à autenticação necessária e a importância de dados criptografados.

Ao invés de realizar apenas testes funcionais execute aqueles que simulem diferentes tipos de ataques. É importante que você conheça para quais tipos de problemas de segurança nas APIs direcionar os testes. Uma ótima fonte de informação é o WHID (Web Hacking Incident Database), que lista os tipos mais prováveis ​​de violação de segurança. Eles são:

• Injeção de SQL;

• Scripts entre sites;

• Negação de serviço;

• Localização previsível de recursos;

• Divulgação não intencional de informações.

Erros de teste de API que você deve passar longe

É preciso cuidado no momento de testar as API, afinal de contas nenhum desenvolvedor quer que todo seu trabalho duro e o uso de recursos disponíveis sejam desperdiçados pela falta de testes ou mesmo pela sua má condução.

Agora que você conhece algumas das melhores práticas relacionadas aos testes de APIs, vale destacar também os principais erros cometidos nessa hora.

1. Considerar o teste de API uma ação autônoma.

A integração de APIs a sistemas e aplicativos é capaz de agregar valor ao negócios e acelerar diversos processos do setor de TI. Logo pôr em prática um teste de API sem levar em conta como a interface pode se comportar no ecossistema é inútil. Os erros das APIs não possuem as mesmas causas, logo o ambiente na qual elas são implementadas tem um importante papel a desempenhar.

O ideal é que todos os times envolvidos na API em questão sejam notificados sobre os resultados dos testes. Se você como desenvolvedor, por exemplo, testar a API por conta própria e não comunicar ao restante da equipe os resultados, há chances de futuras falhas na API.

2. Associar o bom desempenho do aplicativo a qualidade da API

Não há nada de errado em uma API ser integrada ao servidor back-end de um aplicativo móvel com facilidade, na verdade isso é algo muito bom. Entretanto, isso pode transmitir um sentimento de falsa confiança, já que o bom desempenho do aplicativo não descarta a chance de erros básicos na API subjacente. O funcionamento do aplicativo do usuário final não deve se tornar o fator determinante da qualidade de uma API. Existe sim a possibilidade de futuras falhas na interface, levando a uma série de verificações em todos os elementos da cadeia de chamadas. 

3. Esquecer de verificar a escalabilidade

Conforme ocorre um aumento da base de usuários da API também se faz necessário um aumento da própria API. A partir daí é preciso que você coloque a verificação de escalabilidade dentro dos seus testes regulares, evitando as possibilidades de sobrecarga do usuário, juntamente com problemas financeiros e legais. Além de confirmar a escalabilidade adequada da sua API, estabeleça um mecanismo de Governança de API.

4. Ignorar falhas pouco frequentes

É esperado funcionamento constante da API e não apenas a maior parte do tempo, ou seja, falhas pouco frequentes não devem passar batido. Ela ainda sim afetam o desempenho da API. Não é incomum que problemas intermitentes sejam deixados de lados por desenvolvedores, o que é explicado por um simples motivo: a incomoda verificação de todo o log de tráfego da API.

O que você desenvolvedor precisa considerar é que problemas pequenos podem aumentar com o tempo e afetar os usuários finais da API. Por exemplo, um problema ligado a usabilidade, mesmo que pequeno, não deve ser ignorado, muito menos encoberto pelo provedor da API. Se a frequência do problema aumentar com o tempo a depuração da interface também será mais complexa.

Como posso testar minhas APIs?

Existem diversas ferramentas disponíveis no mercado que auxiliam na realização dos testes de APIs. É indicado que no momento de escolha da ferramenta você procure por uma que admita configurar de forma simples os parâmetros do header, o método de request e o body da sua requisição.

Neste artigo irei focar em duas ferramentas muito utilizadas: Postman e SoapUI.

1. Postman

Originalmente o Postman era um plugin do browser Chrome, agora ele possui versões nativas para Mac e Windows. Além dos testes, a ferramenta também ajuda na criação, no compartilhamento e na documentação de APIs. Tudo isso permitindo que o usuário crie e salve suas solicitações HTTP e HTTPs simples e complexas.

Algumas de suas características:

• Permite testes automatizados;

• Facilita testes exploratórios;

• Possui interface rica;

• Ferramenta gratuita, mas possui versão paga para sincronização de código entre equipes;

• Funciona em qualquer plataforma: Windows, MacOS e Linux;

• Converte JSON em várias linguagens (ex: Python, PHP, RUBY);

• Não obriga a equipe de testes a aprender uma nova linguagem de programação.

Um exemplo de empresa que utiliza essa ferramenta para o teste de suas APIs é a Cielo.

2. SoapUI

A SoapUI é ferramenta open source da SmartBear. rata-se de uma solução voltada para o consumo e testes funcional de Web Services, APIs REST e SOAP.

Dentre as suas principais características, vale destacar as seguintes:

• Criação de testes orientados a dados (data driven tests);

• Elaboração de cenários complexos que suportam testes assíncronos;

• Reutilização de scripts;

• Gestão de múltiplo endpoints;

• Realização de testes funcionais, de performance, de segurança e de carga;

• Execução de diversos testes em paralelo;

• Gestão de ambientes de teste;

• Versão gratuita e paga.

Apple, Microsoft e Mastercard são exemplos de empresas que fazem uso dessa ferramenta.

Nunca subestime testes de APIs

As APIs são essenciais para criar uma experiência eficaz e conectada aos clientes e muitas empresas além das de tecnologia já perceberam o real valor de uma API. Em uma época de crescimento constante de aplicativos e plataformas interconectadas a realização de testes em APIs se tornou uma necessidade.

A sua prática pode até ser desafiadora dada a estrutura complexa das APIs, mas eles garantem o controle de qualidade da interface, revelando bugs, inconsistências e desvios do comportamento esperado do aplicativo. O mais indicado é que os testes sejam executados no início do processo de desenvolvimento. Quanto mais cedo um problema for detectado, mais rápido e barato será corrigi-lo. Em 2002 a correção de bugs em softwares custou à economia dos EUA aproximadamente US$ 59,5 bilhões. Já em 2016, esse valor saltou para US$ 1,1 trilhão.

Uma dos principais benefícios da realização dos testes é a rapidez com que eles podem fornecer uma imagem do status do produto no processo de desenvolvimento. Eles também permitem que o desenvolvedor realize teste automatizados a baixo custo, por exemplo, novas startups que não possuem inicialmente capacidade para arcar com grande número de recursos (tempo e pessoas) a fim de criar cobertura mais ampla.

Os testes de API também auxiliam o desenvolvedor a localizar violações que provavelmente seriam perdidas em outros tipos de testes, pois há o risco de o sistema ser tomado por solicitações parametrizadas, mas não apenas isso. O desenvolvedor pode executar ações que não são expostas na interface do usuário (UI), mesmo que seu back-end o ofereça suporte.

Uma vez que você tenha uma API, esta provavelmente será acessada por seus usuários, o que pode deixar você mais aberto a futuras violações. Testar sua API adequadamente oferecerá recursos além dos usuais da UI.

O desenvolvimento e consumo de APIs torna-se cada vez mais constante, especialmente por parte de grandes organizações, afinal a possibilidade de integração de dados é bem atrativa. Entretanto a proteção, segurança e integridade das APIs ainda preocupam qualquer pessoa que trabalhe com elas, e não é para menos, já que um volume altíssimo de dados sensíveis trafegam por elas diariamente.

Caso sua empresa tenha APIs, já parou para avaliar a segurança delas?

Existem alguns aspectos que podem guiar você na melhora da segurança de suas APIs, levando em conta a finalidade destas, sejam para realizar integrações internas ou integrações com aplicações de terceiros.

Vou comentar sobre 4 aspectos da sua API que mais precisam de atenção no momento de estabelecer uma política de segurança de APIs.

Os pontos em que você precisa ficar atento são:

Autenticação e autorização

Provavelmente esta seja a principal preocupação quando estamos falando da segurança de APIs, afinal ninguém gostaria de sofrer o roubo se suas credenciais.

Para garantIr o acesso o acesso a sua API, é importante que você implemente padrões de autenticação e autorização.

Vou comentar sobre alguns deles:

OAuth2

É um protocolo que oferece acesso limitado a recursos de um website sem que os usuários tenham que expor suas credenciais. O OAuth2 tem se firmado como uma das principais formas de autorizar acesso a determinado recurso, principalmente quando tal acesso deve ser concedido pelo próprio usuário. Grandes empresas como Google, Facebook, Twitter e LinkedIn já adotaram esse padrão de autenticação.

OpenID Connect

Este é um protocolo de identidade simples e um padrão aberto. O OpenID Connect foi desenvolvido com base no protocolo OAuth 2 . A partir dele aplicativos de clientes dependem

da autenticação executada pelo OpenID Connect Provider (OP), a fim de verificar a identidade de um usuário.

App Token / JWT

Trata-se de uma chave-de autenticação que identifica o seu cadastro. Ela é necessária para utilizar as APIs disponibilizadas no sistema. Nem preciso dizer o quão importante é a não divulgação da sua chave de acesso, já que através dela podem ser realizadas consultas de informações, que você prefere não divulgar.

Um exemplo de token que você pode utilizar é o JWT (JSON Web Token). Essa técnica definida na RFC 7519 garante a autenticação e autorização de uso de APIs de uma forma segura. Atualmente é o padrão de segurança mais usado para autenticar usuários em APIs RESTful.

É possível validar os dados contidos no JWT a qualquer instante, pois o token é assinado digitalmente, sendo este formado por três seções: Header, Payload e Signature.

Preciso destacar que, independente do protocolo de autenticação/autorização que você escolha, há máximas que você sempre deve seguir: nunca salvar tokens em plain-text e enviar senhas por e-mail.

Privacidade

Termos como Man-in-the Middle, Data Scraping e Network Eavesdropping são comuns para você? Qualquer pessoa que lide de alguma forma com APIs precisa estar familiarizada com essas expressões, já que se referem a ataques a privacidade de APIs, ou seja, eles podem revelar dados sensíveis de seus usuários.

Dessa forma, é essencial que você fique atento às informações que trafegam por meio de APIs. Elas estão sendo disponibilizadas para as pessoas corretas?

A melhor coisa a se fazer para mitigar os riscos é o uso de SSL/TLS.

O certificado SSL (Secure Sockets Layer) aumenta a segurança digital, protegendo suas informações por meio de comunicação criptografada entre a API e navegador. Tal tecnologia, apesar de eficaz, vem sendo continuamente substituída pelo TLS (Transport Layer Security). Esse certificado de segurança é simples e barato de se adquirir, por isso não há desculpas para não utilizá-lo.

Disponibilidade

Monitorar a disponibilidade e o desempenho de sua API, pode auxiliar a detectar comportamentos maliciosos, o que seria um indicativo de ataques do tipo DoS (Denial Of Service), também conhecido como ataque de negação de serviço. Uma tentativa de sobrecarregar o servidor fazendo com que seus recursos fiquem indisponíveis aos usuários.

O que recomendo é instrumentalizar o monitoramento do tráfego em sua API para identificar comportamentos indesejados e pausar possíveis ameaças. Outro recurso é o controle de rate limiting (ou throttling) que limita a quantidade de chamadas aceitas em um determinado período de tempo, podendo ser personalizado por app que está consumindo.

Além disso, implementar uma camada de WAF (Web Application Firewall) para proteger o acesso às suas APIs. Este firewall age como uma barreira entre seu serviço baseado em web e o restante da internet, logo ele monitora, filtra e bloqueia automaticamente o tráfego de dados malicioso. Ele também trabalha para impedir a exposição não autorizada de dados em um site ou aplicativos web. Ao utilizar um WAF você estará menos vulnerável à manipulação de conteúdo exibido (pixação), ataques de injeção em bancos de dados do tipo SQL (Structured Query Language) e fraudes no acesso administrativo.

Integridade

Ataques como injeção de SQL, XML e JSON podem prejudicar e muito a integridade de uma API. o ideal é que você não exponha nenhum recurso ou operação a menos que seja realmente necessário. A recomendação pode parecer até mesmo óbvia, porém ainda há empresas que utilizam técnicas de geração automática de APIs através de geradores de código backend.

Gerenciador de APIs (Gateway)

O Gateway de API age como o principal ponto de controle do tráfego de sua API. Logo, ele atua como um filtro de entrada, direcionando os dados ao ponto mais adequado. Um bom Gateway pode autenticar o tráfego e controlar e analisar o uso das APIs.

O fato de um API Gateway ser capaz de coordenar e controlar vários serviços não o torna completamente imune a ataques, mas sua aplicação garante que o sistema como um todo não será afetado e sim apenas um serviço específico. Dessa forma, além de diminuir os danos em caso de ataques, essa estratégia auxilia os usuários, já que as outras funcionalidades se mantém normais durante um ataque.

Resumindo, um Gateway possui 4 aplicações:

1. Filtro para o tráfego da integração dos meios (mobile, web, cloud, entre outros)

2. Porta de entrada única para diversas APIs que você queira expor

3. Roteador de tráfego de APIs

4. Mecanismos de segurança como autenticação, log e controle de acesso aos usuários e recursos

Quando falamos de empresas que oferecem suporte ao gerenciamento de APIs há diversas opções disponíveis no mercado. Vale destacar empresas estrangeiras como KONG, Red Hat e Apigee. Além deles, temos um grande player nacional reconhecido internacionalmente pelo Gartner como Visionária que é a Sensedia, empresa de tecnologia especializada em todo o Ciclo de Vida de APIs e SOA (Service Oriented Architectures).

As APIs são umas das grandes protagonistas da transformação digital, já que são responsáveis por revolucionar a integração de sistemas, ao mesmo tempo que auxiliam na comunicação entre diferentes tipos de plataformas eletrônicas. Se você já leu alguns dos meus artigos, já sabe do potencial gigantesco quando falo sobre APIs.

A presença dessa tecnologia é cada vez mais rotineira se você levar em consideração a evolução dos sistemas computacionais nos últimos anos, a necessidade de integração de empresas e a crescente busca por serviços oferecidos através da internet. A combinação destes fatores e outros serviu de alavanque para que grandes empresas começassem a investir na integração de interfaces usando APIs.

Como posso dar conta de várias APIs?

O volume de APIs sendo utilizadas por empresas é cada vez maior, já que tais empresas têm se tornado mais abertas em relação aos seus dados e buscam com isso a expansão de seus produtos através de uma rede de parceiros.

Logo é preciso cuidado ao se trabalhar com a comunicação entre vários sistemas, especialmente pela questão de segurança de dados.

Não há como negar a praticidade das APIs, mas ainda sim elas permitem a exploração de falhas por sujeitos mal intencionados. Isso acontece porque parte da documentação que trafega pelas APIs é aberta e pode fornecer pistas sobre como se dá o funcionamento interno de algumas aplicações.

Outro ponto de atenção é que implementações pouco seguras de APIs são alvos fáceis de hackers.

O gerenciamento de diversas APIs, no que concerne sua criação e execução, deve ser também uma preocupação. Por esse motivo, se apoiar em um API Manager é vital para diminuir a exposição dos sistemas da sua empresa. Eles tornam o processos mais simples e dão suporte às equipes de desenvolvedores.

O que é um API Manager?

Um API Manager é um software que implementa uma camada de gestão sobre um API Gateway, adicionando recursos para ajudar a gestão e visualização de dados. Alguns dos resultados são geração de estatísticas de uso de APIs e gerenciamento do ciclo de vida de APIs.

Além de incluir a função Gateway, um API Manager oferece outras possibilidades para melhorar a gestão de suas APIs:

• Dashboards com Insights corporativos de APIs

• Acompanhamento do ciclo de vida das APIs

• Prototipação de APIs

• Monetização das APIs

Ferramentas de gerenciamento de API

No momento dispomos de várias ferramentas para a gestão de API no mercado, que ajudam a catalogar e fazer pesquisas sobre determinada API. Elas também permitem que desenvolvedores de APIs verifiquem se por acaso há outra API com características similares àquela em desenvolvimento. Isso é muito importante para poupar energia e recursos financeiros.

Ferramentas de gestão de APIs também apresentam função de organizar, gerenciar o ciclo de vida de APIs, o que representa não somente publicação e controle de todas as suas versões, mas também as migrações e fluxos de aprovação.

Além disso, outras ferramentas oferecem monitoramento de segurança, tráfego e performance, servindo como proxy de execução de APIs. Algumas das empresas que oferecem essas ferramentas são Apigee, IBM API Management, Microsoft Azure API Management, 3Scale, Kong (open-source e enterprise), Mulesoft, Software AG, 3Scale by RedHat e a nacional Sensedia.

Tais ferramentas são capazes de centralizar suas APIs e permitir a criação de procedimentos de automação, build e release destas sem impacto para quem faz uso delas.

A possibilidade de controlar um ambiente a fim de garantir um bom desempenho, latência baixa e escalabilidade para as APIs também integram os benefícios do uso de uma plataforma de gestão de APIs.

Através de uma plataforma de gerenciamento, você também poderá disponibilizar as APIs em um portal, simplificando sua distribuição e consumo.

Dentre os principais recursos de uma ferramenta de gerenciamento de APIs estão:

• Controle de acesso as APIs

• Proteção de APIs

• Criação e projeto de APIs

• Suporte a modelos híbridos

• Portal de desenvolvedores personalizável

• Alta performance

5 ótimos motivos para investir em uma plataforma de gestão de APIs

Vou apresentar a você algumas das razões que justificam a adoção de uma plataforma de gerenciamento de APIs:

1. Plataforma Robusta

As APIs conseguem realizar diferentes tipos de integração de funcionalidades, mas ainda sim é necessário que o sistema sustente o elevado volume de requisições e, principalmente, os registros das mesmas, facilitando o debugging e também para construção de dashboards para gestão.

Juntamente com o aumento das possibilidades das APIs há também a complexidade desse processo. Assim é importante contar com uma plataforma de gerenciamento para dar suporte às conexões

2. Simplificação de transações

APIs são sinônimo de facilidade quando estamos falando sobre transações de dados entre sistemas e com o apoio de uma plataforma de gerenciamento, é possível assegurar cada vez mais integrações.

3. Autonomia de equipe

A equipe técnica também sai ganhando com o uso de um API Manager, já que passam a ter mais autonomia para alocar recursos, gerenciar transações e acessar serviços. Ao dar autonomia para os times, é possível implementar o conceito de Governança Federada, onde a empresa determina padrões mínimos de implementação, e ao mesmo tempo, o time possui autonomia de gestão e publicação desde que respeite os padrões estabelecidos.

4. Formatos amigáveis

APIs permitem que serviços de aplicativos mais complexos sejam convertidos em formatos mais “amigáveis” para desenvolvedores.

Normalmente, esse processo envolve o uso de um Gateway ou de SOA para converter automaticamente os dados de serviços baseados em SOAP em APIs RESTful.

5. Melhor gestão dos desenvolvedores

Na gestão de APIs você deve lembrar da importância da concessão de recursos para que a equipe de desenvolvedores possam criar aplicações de valor. Nada melhor e mais eficiente que a capacitação da sua equipe através de colaboração interativa e digital.

Uma boa medida é a criação de um portal que simplifique o registro de APIs e promova engajamento da equipe. Isso irá facilitar o compartilhamento de códigos e amostras assim como a realização de fóruns de discussão.

Ferramentas de help desk também colaboram para uma boa gestão de equipes e até otimizam o serviço de gerenciamento de APIs.

Existe plataforma de gestão de APIs ideal?

Antes de mais nada você deve analisar quais são de fato as necessidades de seus times para assim escolher a melhor plataforma de gerenciamento de APIs.

Se seus desenvolvedores criam APIs para uso de sistemas internos, existem algumas ferramentas indicadas especificamente para isso. No entanto, se seu time é responsável pela disponibilização de APIs públicas, por exemplo, a fim de expandir ecossistemas e firmar parcerias, os tipos de plataformas de gestão ideais serão diferentes.

Diferente de integrações do tipo ponto a ponto nas quais um aplicativo se encontra diretamente conectado a uma fonte de dados, as APIs permitem o desacoplamento, ou seja, retiram as dependências diretas entre o aplicativo consumidor da fonte de dados.

Para empresas com um número cada vez mais crescente de sistemas e aplicações que compartilham dados, a integração de APIs faz ainda mais sentido, já que proporciona segurança, flexibilidade, governança, velocidade e reutilização. E justamente sobre este último item que vou comentar neste artigo.

O que é reutilização

Quando falo do reuso de APIs me refiro em optar pela reutilização de uma ou mais funcionalidades de uma API em outras aplicações em vez de adicionar a mesma funcionalidade em uma API existente e em seguida introduzi-la em um aplicativo.

Os beneficiários da reutilização de APIs podem variar dependendo dos negócios da sua empresa:

1. Dentro da própria organização: Acelerar o desenvolvimento de produtos ou serviços que consomem uma determinada informação previamente desenvolvida, como por exemplo, uma API de gerenciamento de endereços pode ser utilizada por uma aplicativo de comércio eletrônico ou sistema ERP.

2. Fora da organização: Ao optar por abrir suas APIs para o mercado, por exemplo, para algum parceiro comercial, a mesma API poderá ser utilizada pelo parceiro para conectar e compartilhar informações em sua solução. No caso de alguma necessidade de personalização, uma nova API deverá será criada, consumindo a API anterior como base para reutilizar as funcionalidades e filtros existentes de acordo com a necessidade e devolvendo apenas as informações necessárias.

Como isso pode ser realizado?

Antes de mais nada, para poder reutilizar uma API, é necessário que você tenha em mente os seguintes tópicos:

1. Objetivo da API

• Qual o problema que ela se propõe a resolver?

• Existe potencial para consumo deste serviço além do contexto de negócio que ela está sendo demandada?

• Quais serão os requisitos para cada cliente consumir?

• Quais são as perspectivas de evolução da API no futuro?

2. Segurança da API

• Quem terá acesso a API?

• Qual o nível de informação será compartilhado com o cliente?

• Existirá limite ou restrição de consumo por quantidade de requisição?

Algo que ajudará no desenho de APIs futuras é compreender a direção geral dos negócios, para que assim seja projetada um API que não supra apenas as necessidades do momento mas as futuras também, garantindo a sua reutilização.

Falar de APIs reutilizáveis significa mais que uma redução de tempo e dinheiro no desenvolvimento, pois o reuso representa uma série de outras vantagens para as empresas como:

1. Entregas mais rápidas de valor ao reutilizar serviços existentes

2. Otimizar custos para evolução constante de serviços reutilizáveis

3. Monetização de serviços com potencial para clientes externos

Como deu para notar, desenvolver uma API já pensando na capacidade de reutilização é uma redução significativa de esforços no futuro, e o que você terá em mãos é uma infraestrutura projetada e preparada para mudanças. Dessa forma é possível avançar com mais velocidade em novos projetos graças aos ativos reutilizáveis e organização integrada.

Como promover a reutilização das APIs

Uma das formas para que possamos promover a reutilização de APIs é justamente tomando conhecimento delas. Pode até parecer um pouco simplório, mas na verdade, ter conhecimentos sobre os tipos de APIs e suas funcionalidades ajudará e muito para que os desenvolvedores encontrem APIs reutilizáveis ao seu propósito.

Para isso nada melhor do que os Portais de APIs. Tais plataformas são de extrema relevância quando a questão é engajamento de desenvolvedores e parceiros. A partir delas seu desenvolvedor poderá publicar e promover suas APIs, sua documentação e gerenciá-las.

Além das informações encontradas nos portais de APIs, é necessário que elas tenham algumas características fundamentais para que posteriormente sejam reutilizadas. As APIs deverão ser fáceis de se usar, pois de nada adianta desenvolver a melhor API do mundo se uso desta não é claro, se sua documentação apresenta legibilidade ruim e se suas respostas não apresentam a velocidade esperada. O que acaba por ocorrer é uma frustração na experiência de consumo e outros desenvolvedores não terão interesse em reutilizá-la.

No decorrer do desenvolvimento da API é importante levar em conta o comportamento dos desenvolvedores e o que se espera. Soluções simples como respostas personalizadas, dicas nos status code e links para documentação já ajudam na compreensão do uso de uma API.

Outro ponto que você deve prestar atenção é quanto a estabilidade da sua API. Os usuários precisam ver que a solução criada a partir da API é confiável, afinal quem pensaria em reutilizar um serviço com uma quantidade significativa de bugs e com falhas em sua performance? Lembre-se: uma API deve apresentar soluções para seus usuários e não gerar obstáculos.

Viver na era da transformação digital implica em muitos aspectos (da nossa vida), principalmente por que a maioria deles gira em torno da dados. Nossa realidade é consequência da abrangência imposta pela Internet, que dissemina e processa informações mais rapidamente assim como facilidade a obtenção de dados.

Não foi nenhuma surpresa que o mercado enxergasse nessas mudanças uma oportunidade e passasse a tratar dados, especialmente os pessoais, como uma nova classe de ativos econômicos, ou seja, um dos recursos mais valiosos da atualidade. Tanto que estima-se que, em 2020, 1,7 MB de dados serão gerados a cada segundo por pessoa, somando 147 Gb de informação por dia.

O valor atribuído a dados faz com que surja ao mesmo tempo uma preocupação com relação a segurança e o devido uso de tais dados. Isso levou a debates sobre a criação de leis para assegurar a proteção de dados pessoais. No Brasil tivemos a promulgação da Lei n° 13.709/2018, a Lei Geral de Proteção de Dados (LGPD) e posteriores modificações em 8 de julho de 2019.

Discutir sobre uma regulamentação de proteção de dados pessoas nos tempos atuais é essencial para segurança e a preservação da privacidade dos usuários. Mas se você pensa que este assunto é algo recente, alguns países além dos que formam a União Europeia já estão à frente do Brasil nesse quesito.

Na verdade, o Brasil é um dos países com a regulamentação mais atrasada na América Latina. No Chile, a legislação de proteção de dados foi decretada em 1999 e, no ano seguinte na Argentina. Colômbia e Uruguai também seguem apresentam avanços no que concerne a segurança da informação.

O que quero dizer é que independente do país de decreto, uma regulamentação de proteção de dados é uma necessidade e tendência global. E há motivos para isso. Segundo a Wired, uma das maiores violações de dados da história ocorreu este ano. Conhecida por “Coleção # 1” a invasão atingiu quase 800 milhões de emails e senhas, totalizando 2.692.818.238 linhas de milhares de fontes diferentes.

A invasão envolveu 772.904.997 endereços de email e mais de 21 milhões de senhas únicas, superando os vazamentos do Equifax e do Yahoo. E não pense que tais casos não são frequentes. Em 2018, o site Business Insider publicou uma lista contendo os 21 maiores episódios de violações revelados.

Se tudo correr como o planejado, a lei deve entrar em vigor em agosto de 2020. Seu objetivo é garantir a privacidade e a segurança dos dados dos usuários A LGPD tem como principal inspiração o Regulamento Geral sobre a Proteção de Dados. (GDPR), norma europeia que entrou em vigor em maio de 2018.

A LGPD propõe em seu texto formas de lidar com dados pessoais, através de normas que irão disciplinar como coletamos, armazenamos, processamos e utilizamos tais informações. É essencial que as empresas brasileiras aproveitem estes meses que antecedem a vigência da LGPD para se adequarem a essa nova realidade de segurança da informação, assim como o conhecerem as normas da legislação.

Os pontos em comum e as distinções

1. Definição de dados pessoais

Da mesma maneira que o GDPR, o novo regulamento de proteção de dados do Brasil, a LGPD, dispõe sobre a definição de dados pessoais para incluir todas as informações relacionadas a uma pessoa identificável e acrescenta restrições especiais referentes ao processamento de dados pessoais confidenciais como gênero, etnia, religião e biometria.

2. Escopos territoriais

Ambos os regulamentos possuem escopos territoriais semelhantes já que se aplicam a todas as empresas que oferecem bens ou serviços a titulares de dados na UE ou no Brasil, independentemente de sua localização. Porém, no caso do GDPR, a regulamentação inclui explicitamente organizações que não estão estabelecidas na UE, contanto que estas monitorem o comportamento dos indivíduos nela localizados. A LGPD não apresenta essa disposição.

3. Bases legais para o processamento de dados

Uma das maiores divergências entre as duas leis está na sua base legal para o processamento de dados. O GDPR inclui o consentimento explícito, desempenho contratual, tarefa pública, interesse vital, obrigação legal e interesse legítimo. Já a LGPD além de incluir as seis acrescenta outras quatro: estudos de um órgão de pesquisa, exercício de direitos em processos judiciais, proteção à saúde e proteção ao crédito.

4. Regulamento de proteção de dados

Para começar, diferente da GDPR, na LGPD certas informações confidenciais adentram a classificação de “dados pessoais” quando são utilizadas para a criação de perfis. Normalmente, tais dados se encontram isentos dos requisitos do regulamento. Porém, de acordo com o artigo 12 eles podem ser considerados dados pessoais “aqueles utilizados para formação do perfil comportamental de determinada pessoa natural, se identificada.”

No caso da GDPR, as empresas com sede ou atuando na União Europeia tinham 2 anos de de preparo e adequação aos requisitos , já as organizações brasileiras tiveram pouco mais de um ano e meio para se preparar, desde o anúncio de aprovação da Lei e sua entrada em vigor.

5. Detalhamento no documento

Algumas das diferenças talvez mais marcantes está no fato de que a lei brasileira apresenta menos descrições e não possui uma introdução explicativa contendo as diretrizes para que seja realizada a interpretação da LGPD. Isso provavelmente torna a implementação da regulamentação da lei mais desafiadora.

6. Comunicação

A lei brasileira também é mais permissiva que a europeia e deixa algumas questões em aberto, como o prazo das notificações obrigatórias de violação de dados: a LGPD estabelece que a comunicação deve ser feita em “prazo razoável”, já a GDPR estipula exatas 72 horas. Infelizmente algumas das previsões da GDPR nem sequer possuem equivalentes na LGDP. O que torna mais forte o questionamento da real eficácia da lei brasileira e se ela conseguirá de fato passar pelos desafios jurídicos e técnicos.

7. Quem está sujeito

Um última divergência que acho válido mencionar é que órgãos públicos também estarão sujeitos à LGPD, ou seja, terão de se adequar às novas medidas, para não seguirem o exemplo da Cambridge Analytica, o famoso caso em que a rede social Facebook foi multada em US$ 5 bilhões (cerca de R$ 19 bilhões). Uma punição por violar, continuamente, os termos de acordo firmado em 2011 com a FTC (Comissão Federal de Comércio) dos EUA, sobre a proteção das informações de privacidade dos usuários da rede.

A necessidade de estar em conformidade com a LGPD

O intervalo de tempo restante até que a LGPD finalmente entre em vigor é curto, mas precisa ser o suficiente para que as empresas consigam se adaptar às novas regras de armazenamento, uso e proteção de dados. O processo em si é repleto de desafios, tanto técnicos quanto jurídicos, como engajar a mudança de cultura na organização, integrar os requisitos da LGPD aos processos existentes, realizar um levantamento do volume e fluxo de dados e identificar riscos.

Diferentes setores terão de buscar a conformidade com a nova regulamentação, mas provavelmente é a área de tecnologia que será mais afetada com a LGPD. Afinal por trabalharem com dados, muitas dessas empresas terão de repensar e reestruturar suas políticas e procedimentos para se tornarem mais compatíveis com a LGPD.

Pense na quantidade crescente de dados sendo produzida diariamente, especialmente os dados pessoais que vem sendo utilizados, coletados e processados por empresas de tecnologia. Não é difícil de imaginar o consentimento do usuário como um dos maiores desafios da LGPD para as empresas do setor.

A partir daí vemos a importância de estruturar sistemas de segurança da informação confiáveis. A chegada ofIcial da LGPD de certa forma obrigará todas as empresas a investirem em setores que talvez antes não recebessem a devida atenção. Para prevenir e detectar a violação de dados, você pode tomar diferentes medidas como novas políticas de privacidade, criptografia (mascaramento de dados), gerenciamento de vulnerabilidades, automação e orquestração de segurança e ferramentas DLP (prevenção contra perda de dados).

Se você quer saber mais sobre Governança de APIs, se cadastre no API Playbook e tenha acesso à entrevistas, video-aulas e materiais voltados ao ciclo de vida de APIs.

Este artigo foi escrito por David Ruiz e publicado originalmente em Prensa.li.