API HTTP base: método, recurso, status y content-type

Una API no empieza en JWT ni en arquitectura hexagonal. Empieza con una request: método, ruta, headers, body y una respuesta con status, headers y body.

Leé una respuesta completa

curl -i muestra headers además del body. Usá una URL pública segura o tu propio servicio local.

curl -i https://example.com

La primera línea te dice protocolo y status. Después vienen headers como Content-Type, Cache-Control o Server.

Método + recurso

Un endpoint debería poder leerse como una frase:

GET    /notes          listar notas
POST   /notes          crear nota
GET    /notes/{id}     ver una nota
PATCH  /notes/{id}     modificar parte de una nota
DELETE /notes/{id}     borrar una nota

Status codes como diseño

No uses 200 para todo. Una API más clara separa casos:

caso                         status razonable
creación correcta             201 Created
sin body, operación exitosa   204 No Content
input inválido                400 Bad Request
no autenticado                401 Unauthorized
sin permiso                   403 Forbidden
recurso inexistente           404 Not Found
conflicto de estado           409 Conflict
fallo inesperado              500 Internal Server Error

Content-Type no es decoración

Si mandás JSON, decilo. Si respondés JSON, decilo también.

curl -i -X POST https://api.example.test/notes \
  -H "Content-Type: application/json" \
  -d '{"title":"nota de juguete"}'

No hace falta que esa URL exista: la evidencia puede ser el diseño de la request y una matriz de endpoints. Si la corrés contra una API propia, usá datos ficticios.