Los métodos HTTP declaran tu intención sobre un recurso; los códigos de estado son la respuesta codificada del servidor. Dos propiedades importan para los métodos: safe (solo lectura, sin efectos secundarios) e idempotent (repetirlo produce el mismo resultado — importante para reintentos seguros).
| Método | Propósito | Safe | Idempotent |
|---|
| GET | Leer un recurso | Sí | Sí |
| POST | Crear / disparar una acción | No | No |
| PUT | Reemplazar un recurso | No | Sí |
| PATCH | Actualizar parcialmente | No | No* |
| DELETE | Eliminar un recurso | No | Sí |
| HEAD | Como GET, solo cabeceras | Sí | Sí |
La distinción de idempotencia es práctica: como PUT y DELETE son idempotentes, un cliente puede reintentarlos con seguridad tras un timeout; reintentar un POST no idempotente arriesga crear un duplicado (el clásico bug de doble cobro).
Los códigos de estado se agrupan por su primer dígito:
1xx Informational request received, continuing (100 Continue, 101 Switching)
2xx Success it worked (200 OK, 201 Created, 204 No Content)
3xx Redirection go elsewhere (301 Moved, 304 Not Modified)
4xx Client error YOUR request is wrong (400, 401, 403, 404, 429)
5xx Server error the SERVER failed (500, 502, 503, 504)
La línea más importante es la separación 4xx vs 5xx: 4xx significa que el cliente envió algo mal (entrada incorrecta, no autenticado, no encontrado) — reintentar sin cambios no ayudará; 5xx significa que el servidor falló — reintentar (con backoff) podría funcionar. Ten dominados los de cada día: 401 (no autenticado) vs 403 (autenticado pero sin permiso), 404 (no encontrado), 429 (limitado por tasa), 500 (crash genérico del servidor), 502/503/504 (bad gateway / no disponible / gateway timeout — normalmente un problema de upstream o de sobrecarga).
Estos códigos son el contrato común entre todo cliente y servidor, así que se espera fluidez aquí de cualquiera que construya o consuma APIs. Los entrevistadores sondean las distinciones que revelan comprensión real: 401 vs 403, PUT vs PATCH, y especialmente la idempotencia, que gobierna directamente si los reintentos son seguros —una preocupación central en sistemas distribuidos y flujos de pago—. Devolver el código de estado correcto también hace que tu API sea predecible y bien manejada por cachés, proxies y librerías cliente, así que este conocimiento moldea un buen diseño de API, no es mera trivia.
Una biblioteca de preguntas de entrevista de IT con respuestas detalladas — de Junior a Senior.
Donar