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:
Nível 0
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.
Nível 1
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.
Nível 2 – RESTful
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.
Nível 3
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:
- O que foi consultado ( **articles **neste exemplo)
- Como está estruturado artigos objetos ( id, titulo, autor, comentarios )
- Como recuperar objetos relacionados (ou seja autor, a lista de comentarios)
- Que há mais artigos (com 10 base no comprimento da resposta atual e links de paginação)
Agora que já conhece um pouco do modelo, onde sua API está?
Podemos chama-la de RESTful ou está mais para RESTbut?
Top comments (0)