El buen diseño de una `REST API` depende mucho de conocer los principales códigos de estado `HTTP`, y el saber como/cuando usarlos; revela nuestra experiencia como desarrollador.

Este post fue publicado originalmente en mi sitio personal

Para ayudar a dominar los códigos de estado al crear API's; dejo este resumen de los códigos HTTP mas usados o mas comunes:

1. 1XX -> Información

2. 2XX -> Petición correcta

3. 3XX -> Redirection

4. 4XX -> Error de cliente

5. 5XX -> Error de servidor.

Hay un tweet de @stevelosh, que define de manera graciosa el objetivo de cada rango o familia de codigos HTTP*.*

English

Spanish

Algunos de los códigos HTTP más usados

Rango 100

• 100 : Es un código muy raro en http, y se puede encontrar al usar websocket. Los websockets usan el código 100 para intercambiar cierta información de protocolo que sirve para establecer la conexión.

Rango 200

• 200 : OK

• 201 : CREATED, devuelve una cabecera location, que es una URL de donde se puede consultar el nuevo recurso, creado.

• 202 : ACCEPTED, encolado en caso de usar colas servicios o workers, también devuelve una cabecera location que es una URL de donde se puede consultar el recurso.

• 204 : NO CONTENT, es como si el servidor te dijera, "te entendí pero no voy a decir nada".

Rango 300

• 301 : MOVED PERMANENTLY, es usado para redirección a largo plazo, el navegador guarda en cache la redirección. Ejm: Cuando la pagina cambio de nombre.

• 302 : ENCONTRADO Y REDIRECCIÓN TEMPORAL, redirecciona a otro lugar. Ejm: Redirección en proceso de login.

• 303 : SEE OTHER

• 304 : NOT MODIFIED, se usa cuando el servidor web implementa algún tipo de cache.

• 307 : TEMPORARY REDIRECT

• 308 : PERMANENT REDIRECT

Importante, tener en cuenta 👇

Los códigos 307 y 308 funcionan como los códigos de respuesta 302 y 301 respectivamente (Redireccion temporal y permanente).

Pero debemos recordar que en una request que use los métodos POST| PUT| DELETE y retorne los códigos 301 o 302; los métodos (POST|PUT|DELETE) se convertiran en una peticion con método GET

• 301 y 302, cambia el método de la peticion por GET.

• 307 y 308, mantienen el método de la peticion(POST, PUT, DELETE).

Rango 400

Se usan cuando el error ha sido provocado por algo que realizo el cliente,

• Ejemplo:

  • Se envió una petición/request mal.

  • No se envió un parámetro obligatorio o requerido.

  • Hace una peticion/request a un URL que no existe.

• 400 : BAD REQUEST.

• 401 y 403 : UNAUTHORIZED AND FORBIDDEN ERRORS.

• 404 : NOT FOUND.

• 410 : GONE, `ya no existe` o `se ha ido`, **Nuevo**

  • Ejm: Cuando se publica un tweet polémico y decides borrarlo; y cuando alguien con el URL quiere volver a ver el tweet, podría devolver 410, porque ha sido eliminado y ya no existe.

• 422 : UNPROCESSABLE ENTITY, en caso de que los parámetros pasados sean inválidos.

  • Ejm: no se envía parámetro correcto o que es obligatorio en la petición.

• 451 : UNAVAILABLE FOR LEGAL REASONS.

Rango 500

En este rango, existen muchos códigos de estados, pero el mas importante es el 500. Se usa cuando hubo un error interno en el servidor.

• Ejm:

  • Una excepción en el código fuente.

  • Un error en la base de datos.

  • Una conexión dañada a algun servidor o peticion, puede darse el caso que nuestro servidor este consultando por detrás a otro servicio y este no este respondiendo a tiempo o con timetout, etc.

• 500 : INTERNAL SERVER ERROR.

• 502 : BAD GATEWAY.

• 503 : SERVICE UNAVAILABLE.

• 504 : GATEWAY TIMEOUT, el servidor esta tardando mucho en responder.

Conclusiones y Recomendaciones

Debemos tener en cuenta que como desarrolladores, a pesar de conocer el error y el códito de estado HTTP exacto que podríamos usar para retornar en el response, aun siendo buena práctica lo anterior, debemos tomar en cuenta desde el punto de vista de la Seguridad, que código debemos usar.

Sería mejor responder un código más genérico y no ser tan específico con el código de estado HTTP que retornemos. Ejm: 500 o 404.

El motivo de esto es para proteger la seguridad de nuestra aplicación o servidor de posible hackers o personas mal intencionadas, y evitar que indaguen en los códigos de respuesta HTTP ya que si detallamos especificando el código HTTP les facilitamos encontrar debilidades que pueda tener nuestro sistema y que no hayamos detectado aún.

Recursos

Aqui hay algunos recursos donde podemos ver mas a detalle los códigos de estado HTTP:

• HTTP Statuses

• HTTP Cats

• HTTP Dogs

• HTTP Status Codes

Referencias

• Obtenido de investigaciones en internet.

• Libro Express in Action.

• Tweet de @stevelosh

• Explicación en el canal de makigas.es.