REST usa HTTP methods estándar como los verbos que actúan sobre los recursos. El mapeo común a CRUD (Create, Read, Update, Delete) es:
REST usa HTTP methods estándar como los verbos que actúan sobre los recursos. El mapeo común a CRUD (Create, Read, Update, Delete) es:
| CRUD | Method | Uso típico |
|---|
| Create | POST | Añadir un nuevo recurso a una collection |
| Read | GET | Obtener un recurso o una lista |
| Update (completo) | PUT | Reemplazar un recurso por completo |
| Update (parcial) | PATCH | Modificar algunos campos |
| Delete | DELETE | Eliminar un recurso |
POST /users HTTP/1.1
Content-Type: application/json
{ "name": "Ann", "email": "[email protected]" }
HTTP/1.1 201 Created
Location: /users/42
{ "id": 42, "name": "Ann", "email": "[email protected]" }
PUT /users/42 envía la representación entera y la reemplaza; PATCH /users/42 envía solo los campos a cambiar (p. ej. { "email": "[email protected]" }).
Son dos propiedades diferentes:
GET, HEAD, OPTIONS son safe.GET, PUT, DELETE, HEAD son idempotent.Method Safe? Idempotent?
GET yes yes
HEAD yes yes
PUT no yes (reemplazar con el mismo body dos veces = mismo resultado)
DELETE no yes (borrar dos veces = sigue borrado)
PATCH no no* (depende del patch; no está garantizado)
POST no no (postear dos veces normalmente crea dos recursos)
Los entrevistadores preguntan esto para ver si entiendes la semántica de HTTP lo bastante bien como para construir APIs fiables. La distinción safe/idempotent no es académica: gobierna directamente lo que clients, proxies y CDNs pueden hacer. Los methods safe pueden cachearse y prefetchearse libremente; los methods idempotent pueden reintentarse automáticamente tras un network timeout sin riesgo de duplicar side effects — por eso un client puede reintentar con seguridad un PUT o un DELETE pero debe tener cuidado al reintentar un POST (podría crear dos orders). El error clásico es usar GET para disparar side effects (p. ej. GET /users/42/delete), lo que rompe el caching y deja que los crawlers muten datos accidentalmente. Elegir el method correcto — y respetar su contrato de safety e idempotencia — es lo que hace que una API sea predecible y segura para construir tooling a su alrededor.
Una biblioteca de preguntas de entrevista de IT con respuestas detalladas — de Junior a Senior.
Donar