Como os métodos HTTP mapeiam para CRUD, e o que significam safe e idempotent?

Question

IT Interview Practice · Accepted Answer

REST usa os **métodos HTTP** padrão como os verbos que agem sobre os recursos. O mapeamento comum para **CRUD** (Create, Read, Update, Delete) é:

| CRUD | Method | Uso típico |
|------|--------|-------------|
| Create | `POST` | Adicionar um novo recurso a uma collection |
| Read | `GET` | Buscar um recurso ou lista |
| Update (completo) | `PUT` | Substituir um recurso inteiramente |
| Update (parcial) | `PATCH` | Modificar alguns campos |
| Delete | `DELETE` | Remover um recurso |

## Exemplos

```http
POST /users HTTP/1.1
Content-Type: application/json

{ "name": "Ann", "email": "ann@example.com" }
```

```http
HTTP/1.1 201 Created
Location: /users/42

{ "id": 42, "name": "Ann", "email": "ann@example.com" }
```

`PUT /users/42` envia a representation **inteira** e a substitui; `PATCH /users/42` envia **apenas os campos a mudar** (ex. `{ "email": "new@example.com" }`).

## Safe vs idempotent

Estas são duas propriedades diferentes:

- **Safe** — o método **não modifica** o estado do server (somente leitura). `GET`, `HEAD`, `OPTIONS` são safe.
- **Idempotent** — fazer o **mesmo request N vezes** tem o mesmo efeito que fazê-lo uma vez. `GET`, `PUT`, `DELETE`, `HEAD` são idempotent.

```text
Method   Safe?   Idempotent?
GET      sim     sim
HEAD     sim     sim
PUT      não     sim      (substituir com o mesmo body duas vezes = mesmo resultado)
DELETE   não     sim      (deletar duas vezes = continua deletado)
PATCH    não     não*     (depende do patch; não garantido)
POST     não     não      (postar duas vezes geralmente cria dois recursos)
```

## Por que isso importa

Os entrevistadores perguntam isto para ver se você entende a semântica do HTTP bem o suficiente para construir APIs confiáveis. A distinção safe/idempotent não é acadêmica: ela governa diretamente o que clients, proxies, e CDNs têm permissão de fazer. Métodos **safe** podem ser cacheados e pré-buscados (prefetch) livremente; métodos **idempotent** podem ser **retentados automaticamente** após um timeout de rede sem risco de duplicar side effects — e é por isso que um client pode refazer com segurança um `PUT` ou `DELETE` mas precisa ter cuidado ao refazer um `POST` (ele pode criar dois pedidos). O erro clássico é usar `GET` para disparar side effects (ex. `GET /users/42/delete`), o que quebra o caching e deixa crawlers mutarem dados acidentalmente. Escolher o método certo — e respeitar seu contrato de safety e idempotência — é o que torna uma API previsível e segura para construir tooling ao redor.

Create	`POST`	Adicionar um novo recurso a uma collection
Read	`GET`	Buscar um recurso ou lista
Update (completo)	`PUT`	Substituir um recurso inteiramente
Update (parcial)	`PATCH`	Modificar alguns campos
Delete	`DELETE`	Remover um recurso

Exemplos

Safe vs idempotent

Por que isso importa

Perguntas relacionadas