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