Backend Web
API (Application Programming Interface)
É um conjunto de regras, padrões e protocolos que permitem que diferentes sistemas
conversem entre si.
O funcionamento da API é baseado nas URLs e utiliza o protocolo HTTP para ditar as
ações que serão realizadas entre os softwares.
Uma grande vantagem na utilização de uma API é a ocultação de informações, permitindo
que um software não precise mostrar completamente como ele funciona, apenas entregar o
resultado esperado.
API REST (Representation State Trasnfer)
O REST é apenas um padrão de design de APIs.
Para uma API ser considerada RESTful ela precisa passar por 7 restrições arquiteturais:
●​ Arquitetura Cliente-Servidor → Onde o frontend e a lógica de armazenamento
conseguem evoluir de maneira completamente independentes.
●​ Ausência de Estado (Statelessness) → Significa que o Cliente e o Servidor jamais
devem armazenar estados anteriores entre si para enviar e receber respostas entre
si. Sempre que uma requisição é enviada ao servidor ele deve conter tudo que é
necessário para que ele responda.
●​ Cache → O servidor deve sempre indicar as informações que podem ser guardadas
no cache do cliente para evitar requisições redundantes.
●​ Sistemas em camadas → O cliente não precisa saber se existem camadas entre
ele e o servidor que o responde.
●​ Código sob demanda → O servidor pode enviar uma requisição com um código
script acoplado que irá rodar em client-side para criar algum efeito..
●​ Interface Uniforme →
○​ Todo recurso é entregue utilizando uma URL própria.
○​ A manipulação de recursos utiliza protocolo HTTP
○​ Não entendi direito o HATEOAS
Recurso
É uma entidade conceitual identificada por uma URL que retorna uma representação, ou
seja, os dados que são enviados daquele entidade.
Idempotência
Quando uma requisição tem o mesmo efeito se for realizada uma vez ou várias vezes. Por
exemplo: Se eu requerer a exclusão de um mesmo dado 5 vezes o resultado será o mesmo
se eu querer a exclusão dele uma vez. Alguns métodos HTTP são idempotentes como
DELETE e PUT (edit) e outros não.
A idempotencia acontece na troca de requisições e respostas entre as API. Pode ser que
uma ação aconteça corretamente no sistema, mas o retorno por falhas de conexão, por
exemplo, não seja coerente com a ação que foi realizada, gerando inconsistência entre a
conversa dos sistemas. Isso poderia gerar ao usuário a repetição de uma ação que já
ocorreu, criando esse problema de duplicação.
A chave de idempotencia precisa ser criada pelo cliente durante a requisição http, assim, se
o usuário estiver na mesma URL de requisicao ele vai enviar sempre a mesma chave.
Como você vai armazenar isso tanto faz (embora seja melhor manter isso num Redis, por
exemplo, ao inves de persistir no banco). A diferença disso para usar o email como chave
única, por exemplo, é que o email é naturalmente um dado da entidade, mas existem
modelos que não possui uma identidade única, como um pagamento.
Paginação
Offset Pagination
É um tipo de paginação por skip do banco. Eu ignoro uma quantidade n de dados e mostro
os próximos m. Ex: BD com 1000 registros. Mostro uma página com 10 registros por vez e
estou na página 3. Ignora os registro do 1 ao 20 e mostro os do 20 ao 30. Fácil
implementação, permite navegação livre entre as páginas, porém com registros muito
grandes de dados por se tratar de complexidade O(n) ele fica mais lento.
Cursor Pagination
É a paginação usando busca por índice, que geralmente utiliza B-Tree como estrutura de
dados para busca. Eu peço então para mostrar todos os ids > 30 com o limite de 10,
utilizando o exemplo do offset e que o id é incremental. Isso reduz drasticamente a busca
no banco e me permite o avanço ou retorno automático das páginas, mas não o avanço
para uma página arbitrária.
A diferença é: Se eu preciso dizer quantos registros eu preciso pular, eu preciso pular eles
um por um, o que é lento, mas permite que eu vá para a página que eu quiser, se eu faço a
busca de uma chave o custo é menor, porque a busca é mais eficiente, mas eu não consigo
pular para uma página específica, porque eu estou usando apenas uma chave como
referência.
Rate Limiting
Limitador de requisições de API, ajuda numa série de questões de segurança, como a
tentativa de senha por força bruta ou ataque DOS que sobrecarrega os recursos do
servidor.
Versionamento
O versionamento das APIs é uma estratégia de evolução e compatibilidade de contratos
entre a API e o consumidor da API, quando as entidades e campos são, por exemplo,
alterados.
Falando em Next.js os problemas de Breaking Changes e versionamento de APIs se
tratando do banco de dados, quando o sistema não precisa ser consumido por sistemas
externos praticamente não existem, porque:
O contrato com o banco e a API são os mesmos, caso haja uma alteração que seria uma
possível Breaking change, basta realizar a migração do banco já que ambos, client e server,
são renderizados em um único monolito.
Breaking changes
Breaking changes são mudanças no contrato da API que podem fazer consumidores
existentes deixarem de funcionar corretamente, como tornar campos obrigatórios, remover
ou alterar resources, modificar o significado de campos ou alterar formatos de resposta. O
breaking change não existe quando, apesar das mudanças, os usuários da API continuam
conseguindo usá-las sem quebras de execução.
Backward compatibility
Backward compatibility, ou compatibilidade retroativa, é a capacidade de uma nova versão
do sistema continuar atendendo consumidores que dependem de versões anteriores do
contrato da API.
Backend Web
API (Application Programming Interface)
É um conjunto de regras, padrões e protocolos que permitem que diferentes sistemas
conversem entre si.
O funcionamento da API é baseado nas URLs e utiliza o protocolo HTTP para ditar as
ações que serão realizadas entre os softwares.
Uma grande vantagem na utilização de uma API é a ocultação de informações, permitindo
que um software não precise mostrar completamente como ele funciona, apenas entregar o
resultado esperado.
API REST (Representation State Trasnfer)
O REST é apenas um padrão de design de APIs.
Para uma API ser considerada RESTful ela precisa passar por 7 restrições arquiteturais:
●​ Arquitetura Cliente-Servidor → Onde o frontend e a lógica de armazenamento
conseguem evoluir de maneira completamente independentes.
●​ Ausência de Estado (Statelessness) → Significa que o Cliente e o Servidor jamais
devem armazenar estados anteriores entre si para enviar e receber respostas entre
si. Sempre que uma requisição é enviada ao servidor ele deve conter tudo que é
necessário para que ele responda.
●​ Cache → O servidor deve sempre indicar as informações que podem ser guardadas
no cache do cliente para evitar requisições redundantes.
●​ Sistemas em camadas → O cliente não precisa saber se existem camadas entre
ele e o servidor que o responde.
●​ Código sob demanda → O servidor pode enviar uma requisição com um código
script acoplado que irá rodar em client-side para criar algum efeito..
●​ Interface Uniforme →
○​ Todo recurso é entregue utilizando uma URL própria.
○​ A manipulação de recursos utiliza protocolo HTTP
○​ Não entendi direito o HATEOAS
Recurso
É uma entidade conceitual identificada por uma URL que retorna uma representação, ou
seja, os dados que são enviados daquele entidade.
Idempotência
Quando uma requisição tem o mesmo efeito se for realizada uma vez ou várias vezes. Por
exemplo: Se eu requerer a exclusão de um mesmo dado 5 vezes o resultado será o mesmo
se eu querer a exclusão dele uma vez. Alguns métodos HTTP são idempotentes como
DELETE e PUT (edit) e outros não.
A idempotencia acontece na troca de requisições e respostas entre as API. Pode ser que
uma ação aconteça corretamente no sistema, mas o retorno por falhas de conexão, por
exemplo, não seja coerente com a ação que foi realizada, gerando inconsistência entre a
conversa dos sistemas. Isso poderia gerar ao usuário a repetição de uma ação que já
ocorreu, criando esse problema de duplicação.
A chave de idempotencia precisa ser criada pelo cliente durante a requisição http, assim, se
o usuário estiver na mesma URL de requisicao ele vai enviar sempre a mesma chave.
Como você vai armazenar isso tanto faz (embora seja melhor manter isso num Redis, por
exemplo, ao inves de persistir no banco). A diferença disso para usar o email como chave
única, por exemplo, é que o email é naturalmente um dado da entidade, mas existem
modelos que não possui uma identidade única, como um pagamento.
Paginação
Offset Pagination
É um tipo de paginação por skip do banco. Eu ignoro uma quantidade n de dados e mostro
os próximos m. Ex: BD com 1000 registros. Mostro uma página com 10 registros por vez e
estou na página 3. Ignora os registro do 1 ao 20 e mostro os do 20 ao 30. Fácil
implementação, permite navegação livre entre as páginas, porém com registros muito
grandes de dados por se tratar de complexidade O(n) ele fica mais lento.
Cursor Pagination
É a paginação usando busca por índice, que geralmente utiliza B-Tree como estrutura de
dados para busca. Eu peço então para mostrar todos os ids > 30 com o limite de 10,
utilizando o exemplo do offset e que o id é incremental. Isso reduz drasticamente a busca
no banco e me permite o avanço ou retorno automático das páginas, mas não o avanço
para uma página arbitrária.
A diferença é: Se eu preciso dizer quantos registros eu preciso pular, eu preciso pular eles
um por um, o que é lento, mas permite que eu vá para a página que eu quiser, se eu faço a
busca de uma chave o custo é menor, porque a busca é mais eficiente, mas eu não consigo
pular para uma página específica, porque eu estou usando apenas uma chave como
referência.
Rate Limiting
Limitador de requisições de API, ajuda numa série de questões de segurança, como a
tentativa de senha por força bruta ou ataque DOS que sobrecarrega os recursos do
servidor.
Versionamento
O versionamento das APIs é uma estratégia de evolução e compatibilidade de contratos
entre a API e o consumidor da API, quando as entidades e campos são, por exemplo,
alterados.
Falando em Next.js os problemas de Breaking Changes e versionamento de APIs se
tratando do banco de dados, quando o sistema não precisa ser consumido por sistemas
externos praticamente não existem, porque:
O contrato com o banco e a API são os mesmos, caso haja uma alteração que seria uma
possível Breaking change, basta realizar a migração do banco já que ambos, client e server,
são renderizados em um único monolito.
Breaking changes
Breaking changes são mudanças no contrato da API que podem fazer consumidores
existentes deixarem de funcionar corretamente, como tornar campos obrigatórios, remover
ou alterar resources, modificar o significado de campos ou alterar formatos de resposta. O
breaking change não existe quando, apesar das mudanças, os usuários da API continuam
conseguindo usá-las sem quebras de execução.
Backward compatibility
Backward compatibility, ou compatibilidade retroativa, é a capacidade de uma nova versão
do sistema continuar atendendo consumidores que dependem de versões anteriores do
contrato da API.