Protocolo HTTP

¿REST y HTTP están ligados? No, ya que es posible utilizar un protocolo diferente al HTTP para establecer la comunicación entre sistemas, pero HTTP se ha posicionado como el más utilizado. Quizá porque HTTP fue creado en función de satisfacer los criterios y prácticas de REST y por el mismo equipo de investigación.

Implementación del protocolo HTTP.

La implementación de HTTP en el API se hará utilizando los “verbos” disponibles para las diferentes operaciones que se realizarán:

Método Descripción Envía datos vía
GET El método GET recupera cualquier información (en forma de entidad) identificada por el URI de solicitud. QueryString
DELETE El método DELETE solicita que el servidor de origen elimine el recurso identificado por el URI de solicitud. QueryString
POST El método POST se utiliza para solicitar que el servidor de origen acepte la entidad incluida en la solicitud, como un nuevo registro del recurso identificado por el URI de solicitud en la línea de solicitud. En el mensaje de retorno se podrá obtener la URL para acceder a la entidad recién creada. Body
PUT El método PUT solicita que la entidad adjunta se modifique bajo el URI de solicitud proporcionado. Body
PATCH El método PATCH solicita que se apliquen cambios a propiedades específicas de una entidad en particular, utilizando el estándar definido por JSON Patch. Body

Lo anterior determina que una petición GET, nunca realizará operaciones que actualicen de ninguna manera los datos de la entidad.

Implementación de los códigos estándar de respuesta de HTTP

Para retornar de las peticiones HTTP, se utilizará la clasificación estándar de los códigos de respuesta.

Rango Categoría Descripción
200-204 Exitosa 200 = OK
201 = Created (Creado exitosamente, es la respuesta a un POST)
204 = No Content (La respuesta fue exitosa a un PUT, PATCH o DELETE y no retorna información)
301-301 Redirección 301 = Moved Permanently (La URL solicitada fue movida a otra ubicación)
400-409 Error Cliente 400 = Bad Request (El cliente envió información inconsistente o que violan reglas de negocio)
401 = Unauthorized (La llamada no ha sido autenticada)
403 = Forbidden (La llamada ha sido autenticada, pero no se tiene permiso al recurso requerido)
404 = Not Found (El recurso requerido no existe)
409 = Conflict (La llave del recurso que se desea agregar ya existe previamente)
500-501 Error Servidor 500 = Internal Server Error (El servidor encontró un error que no le permite responder)
501 = Not Implemented (El cliente hizo una solicitud que no está en las capacidades del servidor)

Manejo de los errores

El manejo de los errores se hará utilizando los códigos de respuesta HTTP, presentados anteriormente. Sin embargo, cada respuesta HTTP errónea, las centenas del 400 y del 500, adjuntarán al cuerpo de la respuesta una clase que tiene un arreglo de todos los errores detectados por el API:

[
  {
    // Id único del Error
    "code": "#####",
    // Mensaje de Error o de Exception
    "internalMessage": "Bad Authentication data.",
    "userMessage": "Necesita iniciar sesión para acceder a los datos.",
    // Id del exception para darle seguimiento
    "traceId": "DzkT9090sadfdMkgIA7V",
    // HTTP Code Status
    "status": 400
  }
]

Si existiera más de un error reportado, el API va a retornar un arreglo de estos objetos.

¿Es útil esta información?
Sí No
En este artículo