API com Spring Boot REST e RESTful com JPA e PostgreSQL -
[Microserviços]
Evolução dos micro serviços na internet
Porque hoje o RESTful tomou conta do mercado e todo projeto
novo, sistema web, principalmente para comunicação entre
sistemas a preferência é a arquitetura REST/RESTful.
Arquitetura SOA (Arquitetura Orientada a Serviços), a
comunicação era feita em forma de xml usando SOAP.
REST é a arquitetura de construção do sistema, quando
pegamos um sistema que estamos criando em cima da
arquitetura REST, durante a implementação dos métodos de
salvar, deletar, consultar, atualizar, etc., aí esses micro
serviços são os RESTful.
Cada micro serviço tem uma responsabilidade bem definida,
esses micro serviços podem ser acessados por outros
sistemas.
Um micro serviço em RESTful pode ser acessado por um
sistema em PHP, Java, C-Sharp e etc., há uma grande
reutilização de código e a complexidade é muito baixa.
O Java tem a parte destinada a arquitetura REST e aos micro
serviços RESTful.
O REST também é uma arquitetura orientada a serviços assim
como o SOA.
Sistemas antigos podem ser transformados em micro serviços
ou webservices (API’s), o que importa em um sistema são as
informações que estão dentro do banco de dados, então todos
os aplicativos que precisam mostrar essas informações eles
irão acessar a mesma base de dados.
Com API’s podemos reutilizar serviços, a API fica no
servidor e é responsável por fazer a conexão com o banco de
dados, o programador realizará o projeto e irá liberar os
endpoints.
Podemos ter um endpoint de salvar aonde a venda será
processada, não importa o tamanho do banco de dados e a
facilidade de integração é muito grande.
Podemos ter diversas plataformas requisitando para o mesmo
endpoint, pode ser um sistema desktop, mobile ou web.
É necessário criar todo o projeto em forma de API sendo que
a regra de negócio deve dar suporte a web, para o usuário
ficará disponível apenas a interface (a tela) pois não
haverá regra de negócio do lado front-end.
É muito comum migrar projetos antigos para a arquitetura de
API’S (Arquitetura REST), principalmente sistemas de loja.
Métodos HTTP de solicitação de requisição
GET – Pedido para recuperar dados. Anotação Spring
@GetMapping.
POST – Envia dados para processar. Anotação Spring
@PostMapping.
PUT – Envia dados para atualizar. Anotação Spring
@PutMapping.
DELETE – Deleta o registro. Anotação Spring
@DeleteMapping.
Solicitação é um pedido de processamento.
Podemos consultar uma venda pelo código usando GET,
consultar uma pessoa pelo CPF.
Para salvar os dados de um cadastro usamos o POST.
Cada método terá a sua devida anotação.
Existem outras solicitações além das quatro citadas acima,
mas são raramente usadas.
Sistemas Amarrados
São sistemas que não usam a arquitetura REST, são sistemas
que não implementam os micros serviços em RESTful.
O front-end depende do back-end e vice-versa, isso ocorre
na arquitetura MVC que está presente em praticamente 90%
das empresas.
São frameworks front-end que dependem do back-end para
poder funcionar, JSF, JSP, ThymeLeaf, PrimeFaces,
BootFaces, Icefaces, entre outros.
Em sistemas amarrados há sempre a necessidade de retornar a
página que será exibida, se for fazer uma manutenção no
back-end é necessário entender que problema poderá vir a
ocorrer no front-end, pois ambos estão amarrados.
Sistemas MVC são amarrados o front-end com o back-end.
Algumas desvantagens da arquitetura MVC
Não é possível reutilizar o back-end.
Não é acessível a mais de uma tecnologia.
Consumo alto de servidor.
Manutenção mais trabalhosa.
Mais trabalhoso para escalar (colocar mais clientes
acessando).
Criar instancias diferentes em servidores, por exemplo
um servidor cai e o outro assume.
Um serviço RESTful não é amarrado a nenhuma tecnologia
front-end, por isso um webservice RESTful em java por
exemplo pode ser acessado por qualquer tecnologia front-end
como JSF, PrimeFaces, ThymeLeaf e etc.
O REST soluciona o problema de troca de informações entre
sistemas.
Sistemas em arquitetura REST
Qual é a funcionalidade principal em sistema REST? Ele irá
retornar apenas um JSON em dados, que são informações em
formato texto (notação literal de objeto).
JSON podemos transformar em objetos e usar em diferentes
tecnologias, pode-se trocar o back-end sem precisar se
preocupar com o front-end pois um não é amarrado ao outro.
Quando se muda uma arquitetura também se muda os frameworks
por isso que há a necessidade de se levantar os requisitos
quando for criar um sistema.
É necessário levantar os requisitos da arquitetura para
depois escolher os frameworks.
O AJAX (jQuery) faz a requisição (POST, PUT, DELETE, GET)
passando o que quer executar seja parâmetros ou dados e por
fim cai em um método do servidor que irá processar e
retornará um JSON.
Não se retorna mais páginas amarradas com dados como
acontecia na arquitetura MVC. O JSON é a resposta do pedido
de processamento que foi executado no servidor.
Existe somente pedido e resposta em JSON via Ajax.
É possível criar o front-end em Angular e depois migrar
para React sem precisar alterar uma única linha no back-
end.
Podemos colocar a parte de front-end em um servidor e parte
de back-end em outro servidor, o melhor é colocar em
servidores separados.
Vantagens da arquitetura REST
Reutilização de código.
Acessível por qualquer tecnologia.
Baixo consumo do servidor.
Fácil manutenção.
Fácil implementação de recursos.
Front-end desamarrado do back-end.
Front-end e Back-end podem ser trocados sem que um
afete o outro.
Alta escalabilidade (ter alta demanda com qualidade).
Por exemplo podemos fazer uma requisição Ajax de consulta
de pessoa pelo número do CPF, então fazemos uma consulta
(GET) passando por parâmetro o número do CPF.
Front-end e Back-end podem ser criados em projetos
separados e colocados em servidores distintos.
Modelagem correta de URI’s
Existem muitos sistemas que dizem ser em REST (que de certa
forma não deixa de ser) mas estão fora do padrão. Quando se
fala em REST deve se pensar em simplicidade e facilidade.
Não podemos amarrar o sistema, todo tipo de sistema pode
consumir nossa API, a manutenção deve ser fácil e não pode
quebrar, temos que pensar em vários fatores para ter uma
API REST elegante, usável, escalável, consumo facilitado.
Não se deve confundir URI com URL, url é por exemplo
[Link] isso é uma url.
URI é como iremos acessar o nosso método RESTful, então
iremos usar os verbos HTTP (GET, POST, PUT e DELETE) para
acessar os serviços da nossa API.
Não se pode expor o que a URI está fazendo dando nome de
verbo para a URI, por exemplo:
GET -> /buscarCliente/1 -> visualizar
POST -> /salvarCliente -> criar
PUT -> /alterarCliente/1 -> Alterar
DELETE -> /deletarCliente/1 -> Remover
Veja abaixo a maneira correta de se criar URI:
GET -> /cliente/1 -> visualizar
POST -> /cliente -> criar
PUT -> /cliente/1 -> atualizar
DELETE -> /cliente/1 -> Remover
No POST não tem o /valor pois estamos enviando um objeto
inteiro para ser salvo.
A URI deve seguir sempre o mesmo padrão.
O verbo HTTP define a ação do que será realizado, então não
é necessário escrever o que será feito.
A URI será acessada pelo framework javaScript.
A modelagem de REST é em cima de verbos que define a ação.
[Link]
desenvolvimento-de-apis-rest
6 Regras da da API RESTful verdadeira
A API tem que seguir exatamente os seis passos a seguir
para ser considerada uma API RESTful verdadeira.
Tem que existir os dois papéis, o cliente e o
servidor.
Stateless, o sistema não pode ter sessões amarradas ou
criadas para o cliente e as requisições tem que ter
todos os dados para o processo ser realizado e a
resposta ser completa.
Precisa permitir que o cache seja feito caso
necessário.
Interface uniforme – a API não pode fazer distinção de
clientes, não pode diferenciar e processar algo
diferente para navegador,