Concluímos esta serie de post:
Buenas Prácticas para diseñar una API RESTful-pragmatic (Parte I)
Buenas Prácticas para diseñar una API RESTful-pragmatic (Parte II)
con los códigos HTTP a usar en un API RESTful:
- 200 OK – Respuesta a una acción con éxito GET, PUT, PATCH o DELETE. También se usa para POST que no desencadena una creación
- 201 Created – Respuesta a un POST que realiza una creación. Se suele acompañar a un puntero a la localización del nuevo recurso
- 204 No Content – Respuesta a una petición correcta que no devuelve body (como una petición de DELETE)
- 304 Not Modified – Usado con cabeceras de cacheo HTTP
- 400 Bad Request – La petición está malformado, como si no se puede parsear el body
- 401 Unauthorized – Cuando no se pasan datos de autenticación o estos son erróneos
- 403 Forbidden – Cuando la autenticación funciona pero el usaurio autenticado no tiene acceso al recurso
- 404 Not Found – Cuando se solicita un recurso no existente
- 405 Method Not Allowed – Cuando se solicita un método HTTP que no es permitido para el Usuario autenticado
- 410 Gone – Indica que el recurso en este endpoint ya no existe. Se usa para versiones de APIs antiguas
- 415 Unsupported Media Type – Si el content-type provisto es incorrecto
- 422 Unprocessable Entity – Usado para errores de validación
- 429 Too Many Requests – Cuando una petición se descarta debido a limitación de cuota
