Métodos HTTP

El metodo GET solicita una representacion del recurso especificado. Las solicitudes GET solo deben recuperar datos y no tener ningun otro efecto sobre el recurso. Dado que las solicitudes GET no modifican el estado, se consideran seguras e idempotentes.

GET /api/users/123 HTTP/1.1
Host: api.example.com
Accept: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: max-age=60

{
  "id": 123,
  "name": "Alice Johnson",
  "email": "alice@example.com",
  "role": "admin",
  "createdAt": "2025-08-14T10:30:00Z"
}

El metodo POST envia una entidad al recurso especificado, causando frecuentemente un cambio de estado o efectos secundarios en el servidor. Se utiliza comunmente para crear nuevos recursos o desencadenar operaciones. POST no es seguro ni idempotente, lo que significa que solicitudes identicas repetidas pueden crear recursos duplicados.

POST /api/users HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

{
  "name": "Bob Smith",
  "email": "bob@example.com",
  "role": "member"
}

HTTP/1.1 201 Created
Content-Type: application/json
Location: /api/users/456

{
  "id": 456,
  "name": "Bob Smith",
  "email": "bob@example.com",
  "role": "member",
  "createdAt": "2026-03-02T14:22:00Z"
}

El metodo PUT reemplaza todas las representaciones actuales del recurso objetivo con el contenido de la solicitud. Si el recurso no existe, PUT puede crearlo. PUT es idempotente, lo que significa que realizar la misma solicitud multiples veces produce el mismo resultado que realizarla una sola vez.

PUT /api/users/123 HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

{
  "name": "Alice Johnson-Smith",
  "email": "alice.js@example.com",
  "role": "admin"
}

HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": 123,
  "name": "Alice Johnson-Smith",
  "email": "alice.js@example.com",
  "role": "admin",
  "updatedAt": "2026-03-02T15:10:00Z"
}

El metodo PATCH aplica modificaciones parciales a un recurso. A diferencia de PUT, que reemplaza el recurso completo, PATCH solo actualiza los campos proporcionados en el cuerpo de la solicitud. PATCH no es seguro ni necesariamente idempotente, aunque puede implementarse de forma idempotente.

PATCH /api/users/123 HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

{
  "email": "alice.new@example.com"
}

HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": 123,
  "name": "Alice Johnson",
  "email": "alice.new@example.com",
  "role": "admin",
  "updatedAt": "2026-03-02T15:45:00Z"
}

El metodo DELETE elimina el recurso especificado del servidor. Despues de un DELETE exitoso, las solicitudes GET subsiguientes a la misma URI deberian devolver 404 Not Found. DELETE es idempotente, lo que significa que eliminar un recurso ya eliminado no deberia producir un error mas alla de la eliminacion inicial.

DELETE /api/users/123 HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

HTTP/1.1 204 No Content
X-Request-Id: req_abc123

El metodo HEAD es identico a GET excepto que el servidor no debe devolver un cuerpo de mensaje en la respuesta. Es util para verificar si un recurso existe, inspeccionar encabezados o probar enlaces sin descargar la respuesta completa. HEAD es seguro e idempotente.

HEAD /api/users/123 HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

El metodo OPTIONS describe las opciones de comunicacion disponibles para el recurso objetivo. Se utiliza comunmente en solicitudes preflight de CORS donde el navegador verifica que metodos HTTP y encabezados estan permitidos antes de enviar la solicitud real. OPTIONS es seguro e idempotente.

OPTIONS /api/users HTTP/1.1
Host: api.example.com
Origin: https://app.example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: Content-Type, Authorization

El metodo TRACE realiza una prueba de bucle de mensaje a lo largo de la ruta hacia el recurso objetivo, devolviendo la solicitud recibida como eco. Se utiliza principalmente con fines de diagnostico para ver como los proxies intermedios modifican la solicitud. TRACE rara vez se usa en APIs de produccion y a menudo esta deshabilitado por razones de seguridad.

TRACE /api/users HTTP/1.1
Host: api.example.com
Max-Forwards: 3

El metodo CONNECT establece un tunel hacia el servidor identificado por el recurso objetivo. Se utiliza principalmente con proxies HTTP para iniciar una conexion TLS/SSL de extremo a extremo a traves del proxy, permitiendo que el trafico HTTPS pase por un proxy HTTP. CONNECT no es seguro ni almacenable en cache.

CONNECT api.example.com:443 HTTP/1.1
Host: api.example.com:443
Proxy-Authorization: Basic dXNlcjpwYXNz