¿Qué pertenece en un encabezado de solicitud HTTP versus el cuerpo de la solicitud?

Estoy trabajando en un conjunto de servicios web para un cliente móvil, y los requisitos requieren que se incluya una identificación de dispositivo única con todas las solicitudes, que se almacene en ciertas solicitudes y se use para filtrar resultados en otras.

Se sugirió que se colocara en un encabezado HTTP personalizado, ya que se incluirá con todas las solicitudes, por lo que comencé a preguntarme qué criterios podrían usarse para determinar si un dato dado pertenece a un encabezado o junto con otros datos en El cuerpo de la solicitud.

¿Hay algún criterio de este tipo?

Cuando la información es importante, debe ponerla en el cuerpo.

¿Por qué?

1. Los servidores proxy pueden modificar los encabezados. Muchos están configurados para quitar cualquier encabezado que no conozcan. Sin embargo, esto solo se aplica cuando utiliza HTTP sin cifrar. Cuando usa HTTPS, el proxy no puede cambiar los encabezados porque están encriptados.
2. Cuando usa un servicio web, generalmente lo hace para la interoperabilidad con otros dispositivos, servicios y herramientas. La mayoría de las API y herramientas que funcionan con servicios web pueden cambiar fácilmente las solicitudes, pero muchas hacen que sea difícil o incluso imposible agregar encabezados personalizados. Esto, por supuesto, solo se aplica cuando la interoperabilidad es una preocupación. Pero cuando no le importa, es posible que desee preguntarse por qué está utilizando servicios web en primer lugar, en lugar de simplemente construir su propio protocolo en TCP sin procesar.

Si bien la línea es algo borrosa, para mí una regla general es: los datos en los que trabaja su lógica de negocios deben estar en el cuerpo, los metadatos pueden / deben colocarse en encabezados.

Otra forma de verlo es: los datos que aparecen solo en tipos específicos de solicitudes deben estar en el cuerpo, mientras que los datos que se manejan de manera consistente en toda la aplicación deben ir a los encabezados.

Otro punto de vista es: ¿te imaginas que un dato se maneja globalmente, por ejemplo, por un enrutador / firewall en lugar de por tu aplicación? En caso afirmativo, probablemente debería ir en los encabezados en lugar de en el cuerpo.

Algunos ejemplos de aplicación de estas reglas serían:

• Las credenciales de seguridad van en los encabezados, ya que lo más probable es que se manejen de la misma manera en todos los lugares de una aplicación; a nivel de implementación probablemente habrá algún filtro de solicitud que rechace solicitudes sin credenciales válidas, independientemente del punto final real que maneja la solicitud en caso de que atraviese el filtro.
• Si, por otro lado, tiene un punto final que permite que un administrador agregue usuarios a su sistema, el inicio de sesión del usuario que se creará debe estar en el cuerpo de la solicitud, ya que: a) es manejado por la lógica comercial de su aplicación, b) aparece en este punto final particular pero no en otros.
• Las opciones que controlan el almacenamiento en caché pueden encajar bien en los encabezados (a menos que el almacenamiento en caché sea una parte central de la lógica empresarial de su aplicación).

Volviendo a su pregunta sobre la ID única del dispositivo: si se usa de manera consistente en todas partes, por ejemplo, solo para iniciar sesión, se puede colocar en los encabezados. Pero si se usa para filtrar solicitudes de diferentes maneras según el punto final, será mejor que esté en el cuerpo. Por supuesto, si tiene ambos casos de uso, probablemente sea mejor quedarse con una sola forma de pasarlo (probablemente los encabezados) en lugar de obligar al usuario de la API a colocar los mismos datos en dos lugares, dándole el dilema de permitir entradas inconsistentes o implementando algún tipo de validación.

El contenido de la solicitud del cliente; que no se cambiará a través de múltiples solicitudes al mismo servidor formará parte de HEADER, por ejemplo, credenciales, otras que son cambios frecuentes por solicitud formarán parte de BODY.

O

La propiedad del contenido del mensaje / cuerpo irá al encabezado. por ejemplo) tipo de codificación, longitud de contenido, tipo de contenido.

Y

En su caso, los parámetros de filtro similares deben agregarse como parámetros de consulta / solicitud en la url.

/mobiles?type=MOTO&colour=black

En los servicios de descanso, la URL en sí se referirá a un objeto.

/conferences/{conference_id} -> refiere conferencia específica