DEV Community

Carlos Viana
Carlos Viana

Posted on

Modelo de Maturidade Richardson (RMM)

O Modelo de Maturidade de Richardson é uma estrutura proposta por Leonard Richardson para avaliar o quão "RESTful" uma API é, com base em sua aderência aos princípios do REST. Ele divide a maturidade em quatro níveis (0 a 3), cada um representando um grau crescente de conformidade com o estilo arquitetural REST. Abaixo está uma explicação clara e concisa de cada nível:

Nível 0: The Swamp of POX (Pântano de POX)

  • Descrição: APIs neste nível não seguem os princípios REST. Elas usam HTTP como um transporte simples, geralmente com um único endpoint e método (ex.: POST) para todas as operações, semelhante a chamadas remotas de procedimento (RPC). O termo "POX" significa "Plain Old XML", mas pode incluir JSON ou outros formatos.
  • Características:
    • Um único URI (ex.: /api) para todas as requisições.
    • Uso exclusivo de POST para enviar comandos ou dados.
    • Sem aproveitamento dos recursos do HTTP (métodos, códigos de status, etc.).
    • Respostas não representam recursos, mas sim resultados de ações.
  • Exemplo: Enviar um XML via POST /api com uma instrução como <action>getUser</action><id>123</id> para recuperar um usuário.
  • Problema: Baixa interoperabilidade, difícil de escalar ou entender.

Nível 1: Recursos

  • Descrição: O primeiro passo rumo ao REST. Aqui, a API começa a identificar recursos individuais com URIs específicas, mas ainda não usa os métodos HTTP adequadamente.
  • Características:
    • Cada recurso tem seu próprio URI (ex.: /users/123, /books/1).
    • Geralmente, ainda usa apenas POST para todas as operações (criar, ler, atualizar, deletar).
    • Não explora os códigos de status HTTP ou métodos como GET, PUT, DELETE.
  • Exemplo: POST /users/123 para obter ou atualizar o usuário 123, sem diferenciar a operação.
  • Benefício: Introduz a ideia de recursos, facilitando a organização.
  • Limitação: Não aproveita a semântica do HTTP, o que reduz a clareza e a eficiência.

Nível 2: Verbos HTTP

  • Descrição: A API começa a usar os métodos HTTP (GET, POST, PUT, DELETE) de forma adequada para operar nos recursos, além de explorar códigos de status HTTP para indicar o resultado das operações. Este nível é onde muitas APIs RESTful modernas operam.
  • Características:
    • Métodos HTTP são usados corretamente:
    • GET /users/123: Recupera o usuário 123.
    • POST /users: Cria um novo usuário.
    • PUT /users/123: Atualiza o usuário 123.
    • DELETE /users/123: Deleta o usuário 123.
    • Códigos de status HTTP são usados (ex.: 200 OK, 201 Created, 404 Not Found, 400 Bad Request).
    • URIs representam recursos, não ações.
  • Exemplo: GET /books/1 retorna o livro com ID 1 com status 200; POST /books cria um livro e retorna 201.
  • Benefício: Maior clareza, interoperabilidade e uso correto do protocolo HTTP.
  • Limitação: Ainda não suporta navegação dinâmica entre recursos.

Nível 3: HATEOAS (Hypermedia as the Engine of Application State)

  • Descrição: O nível mais avançado de maturidade REST. A API implementa HATEOAS, onde as respostas incluem links para outras ações ou recursos relacionados, permitindo que o cliente "navegue" pela API como em um site web. Isso torna a API mais autodescritiva e resiliente a mudanças.
  • Características:
    • Respostas contêm links para ações possíveis (ex.: { "id": 123, "name": "John", "_links": { "self": "/users/123", "delete": "/users/123", "update": "/users/123" } }).
    • O cliente não precisa conhecer URIs fixos; ele segue os links fornecidos.
    • A API guia o estado da aplicação por meio de hipermídia.
  • Exemplo: Uma resposta GET /users/123 pode incluir links como: 
  {
    "id": 123,
    "name": "John",
    "_links": {
      "self": { "href": "/users/123" },
      "orders": { "href": "/users/123/orders" },
      "delete": { "href": "/users/123", "method": "DELETE" }
    }
  }
Enter fullscreen mode Exit fullscreen mode
  • Benefício: Flexibilidade máxima, resiliência a mudanças (ex.: URIs podem mudar sem quebrar o cliente) e maior descoberta de funcionalidades.
  • Limitação: Complexo de implementar e nem sempre necessário para APIs simples.

Resumo dos Níveis:

  • Nível 0: HTTP como transporte, sem recursos ou métodos (RPC-like).
  • Nível 1: Introduce recursos com URIs, mas ainda usa HTTP de forma limitada.
  • Nível 2: Usa métodos HTTP e códigos de status corretamente (padrão para APIs RESTful).
  • Nível 3: Adiciona HATEOAS, tornando a API navegável e autodescritiva.

Observações:

  • Nível 2 é suficiente para a maioria das APIs: Muitas APIs modernas param no Nível 2, pois o Nível 3 (HATEOAS) é complexo, no entanto, o Nível 3 (HATEOAS) promove uma maior flexibilidade e capacidade de descoberta, permitindo que o cliente navegue e interaja com a API de forma mais dinâmica, ao fornecer links para ações possíveis.
  • Como usar o modelo: O modelo serve como um guia para avaliar e melhorar APIs, mas não é uma regra rígida. A escolha do nível depende das necessidades do projeto (Tente implementar o possível).

Para saber mais martinfowler.com/articles/richardsonMaturityModel

Top comments (0)