Search for a command to run...
Conheça os 4 níveis de maturidade API para ser considerada RESTful
I'm Sassine, Java Specialist and Engineering Manager at NTT DATA, based in Brazil. My main strengths are architecture, performance, quality and agility in the Java and Spring universe with AWS.
Sou Sassine, especialista em Java e gerente de engenharia da NTT DATA, com sede no Brasil. Meus principais pontos fortes são arquitetura, desempenho, qualidade e agilidade no universo Java e Spring com AWS.
No comments yet. Be the first to comment.
A nova abordagem recomendada pelo Spring para fazer chamadas de API de forma reativa ou bloqueante
Percorra, manipule, converta... suas listas de forma performática com Stream
Introdução Sempre que estou entrevistando um novo candidato eu o questiono sobre o uso ou conhecimento do Optional, e quase sempre ouço a mesma resposta "Já utilizei, quando usei o JPA "😢 📦 Caso queira acompanhar a classe completa enquanto lê o art...
Principalmente os dados de entrada de saída de sua API.
Conheça as grandes melhorias de cada versão do Java
Você conhece o Modelo de Maturidade de Richardson?
Leonard Richardson propôs um Modelo de Maturidade para avaliar APIs REST que foi usado na Bíblia do REST, o livro REST in Practice, do Jin Webber de 2010 (sim, publicado a 11 anos!). ⠀ Nesse modelo, são propostos 4 níveis de maturidade:
Definitivamente neste nível não podemos nem chamar de REST. Neste nível estamos apenas usando o protocolo HTTP, sem nenhuma padronização POX (Plain Old XML).
Identificação de recursos – você usa o padrão URI (IRI) para identificar um recurso. Nesse caso, um recurso é um documento da web.
Agrupamos as capacidades em Recursos, tornando suas APIs um pouco mais organizadas, mas ainda não é uma RESTful.
Manipulação de recursos por meio dessas representações – você usa o padrão HTTP para descrever a comunicação. Portanto, por exemplo, GET significa que você deseja recuperar dados sobre o recurso identificado pelo URI. Você pode descrever uma operação com um método HTTP e um URI.
Aqui usamos corretamente os verbos HTTP (ou seja, as APIs usam a Uniform Interface). Neste ponto, eu já consigo chamar a API de RESTful, apesar de ser difícil encontrar APIs que atingiram completamente os 2 primeiros níveis
Mensagens autodescritivas – você usa tipos MIME padrão e vocabs RDF (padrão) para tornar as mensagens autodescritivas. Assim, o cliente pode encontrar os dados verificando a semântica e não precisa saber a estrutura de dados específica do aplicativo que o serviço usa.
Finalmente no nível 3 usamos Controles Hypermedia, chegando ao HATEOAS.
Hipermídia como mecanismo de estado do aplicativo (também conhecido como HATEOAS) – Você usa hiperlinks e possivelmente modelos de URI para separar o cliente da estrutura URI específica do aplicativo. Você pode anotar esses hiperlinks com semântica, por exemplo, relações de link da IANA, para que o cliente entenda o que eles significam.
{
"links": {
"self": "https://sassine.dev/artigos",
"next": "https://sassine.dev/artigos?page[offset]=1",
"last": "https://sassine.dev/artigos?page[offset]=40"
},
"data": [{
"type": "artigos",
"id": "4",
"attributes": {
"titulo": "REST(ful) ou REST(but)"
},
"relationships": {
"autor": {
"links": {
"self": "https://sassine.dev/articles/4/author",
"related": "https://sassine.dev/articles/4/author"
}
},
"comentarios": {
"links": {
"self": "https://sassine.dev/articles/4/comments",
"related": "https://sassine.dev/articles/4/comments"
}
}
},
"links": {
"self": "https://sassine.dev/artigos/4"
}
}]
}
Apenas analisando esta única resposta, um cliente sabe:
Agora que já conhece um pouco do modelo, onde sua API está? Podemos chama-la de RESTful ou está mais para RESTbut?