Conceptos Fundamentales de Métodos HTTP y Principios REST

Métodos HTTP Esenciales

A continuación, se describen los métodos HTTP más comunes y sus características:

GET

• Propósito: Devuelve información del recurso identificado.
• Seguro: Sí (la ejecución no altera el estado del recurso).
• Idempotente: Sí (su ejecución repetida produce el mismo efecto que una única ejecución).
• Códigos de estado comunes:
  • 200 OK: Si todo va bien y se encuentra el recurso.
  • 204 No Content: Si el recurso existe, pero no hay contenido para devolver.

POST

• Propósito: Permite crear nuevos recursos en el servidor o enviar datos para que los recursos los procesen, realizando cambios en su estado.
• Seguro: No.
• Idempotente: No.
• Códigos de estado comunes:
  • 201 Created: Si el recurso se crea exitosamente, junto con la localización del nuevo recurso en la cabecera Location.

PUT

• Propósito: Actualiza un recurso existente en el servidor. También puede utilizarse para crear nuevos recursos cuando el cliente puede decidir su URI y anticipar la identidad del recurso.
• Seguro: No.
• Idempotente: Sí.
• Códigos de estado comunes:
  • 200 OK: Si el recurso se actualiza correctamente.
  • 201 Created: Si se crea un nuevo recurso (cuando el cliente especifica la URI).

DELETE

• Propósito: Elimina un recurso en el servidor.
• Seguro: No.
• Idempotente: Sí.
• Códigos de estado comunes:
  • 200 OK: Si el recurso es eliminado correctamente (con una respuesta).
  • 204 No Content: Si el recurso es eliminado correctamente (sin contenido en la respuesta).
  • 404 Not Found: Si el recurso no existe en el momento de la petición.

Definiciones Clave en HTTP

• Seguro: Un método es seguro cuando su ejecución no altera el estado del recurso en el servidor y no se espera que cause efectos colaterales (principalmente operaciones de lectura).
• Idempotente: Un método es idempotente cuando su ejecución repetidas veces sobre un mismo recurso provoca el mismo efecto que una única ejecución (salvo por condiciones de carrera).

Obtención de Datos en Diferentes Formatos: Negociación de Contenido

El mecanismo para obtener datos en diferentes formatos es la negociación de contenido. Este permite que un recurso identificado por una URI única pueda tener múltiples representaciones (por ejemplo, JSON, XML, HTML).

Cada representación debe ser tipada, y para ello se utilizan los tipos MIME (Multipurpose Internet Mail Extensions).

Para utilizar este mecanismo:

• El cliente utiliza la cabecera Accept en su petición, donde especifica los tipos de medios que acepta como respuesta (ej., Accept: application/json, text/xml).
• El servidor, por su parte, utiliza la cabecera Content-Type en su respuesta para especificar el tipo del cuerpo de la misma (ej., Content-Type: application/json).

Solución para Peticiones de Larga Duración: Peticiones Asíncronas

Para evitar que el cliente se quede esperando una respuesta de una operación de larga duración, se utilizan las peticiones asíncronas.

En este escenario:

1. Cuando el servidor recibe una petición que requiere un procesamiento prolongado, devuelve inmediatamente el código de estado 202 Accepted. Este código desbloquea al cliente que estaba esperando una respuesta.
2. Junto con el 202 Accepted, el servidor proporciona la localización (URI) donde el cliente puede consultar el estado de la petición en curso.
3. Si la petición inicial no se puede procesar (por ejemplo, debido a errores de validación), el servidor devolverá los códigos de error correspondientes (4xx o 5xx) de inmediato.
4. El cliente, entonces, realiza un proceso de polling (consulta periódica) utilizando el método GET sobre la URI proporcionada para consultar el estado de la petición.

Durante el polling, el cliente puede obtener los siguientes resultados:

• 200 OK (en proceso): Junto con información detallada sobre el estado actual de la tarea.
• 200 OK (finaliza con error): Junto con la información del error con el que ha terminado la tarea. (Si estas peticiones de polling no se han podido procesar correctamente, el servidor devolverá los códigos de error correspondientes, como 5xx).
• 303 See Other: Si la tarea finaliza con éxito. En este caso, la respuesta incluirá una cabecera Location con la URI de un recurso que muestre el resultado final de la tarea.

Antipatrón: HTTP Tunneling

El HTTP Tunneling es un uso incorrecto de los principios REST.

Consiste en utilizar un método POST sobre una misma URI para realizar diferentes acciones que deberían ser manejadas por otros métodos HTTP (por ejemplo, simular un DELETE o un PUT). Esto viola la semántica de los métodos HTTP y la uniformidad de la interfaz REST.

Para eliminar un recurso, por ejemplo, debe utilizarse el método DELETE sobre la URI específica del recurso a eliminar, y no un POST con un parámetro que indique la acción "eliminar".