O que pertence a um cabeçalho de solicitação HTTP versus o corpo da solicitação?

Estou trabalhando em um conjunto de serviços da Web para um cliente móvel, e os requisitos exigem que um ID de dispositivo exclusivo seja incluído em todas as solicitações, seja armazenado em determinadas solicitações e usado para filtrar resultados em outras.

Foi feita uma sugestão de que ele fosse colocado em um cabeçalho HTTP personalizado, uma vez que será incluído em todas as solicitações, então comecei a pensar em quais critérios poderiam ser usados ​​para determinar se um dado dado pertence a um cabeçalho ou junto com outros dados em o corpo da solicitação.

Existe algum desses critérios?

Quando a informação é importante, você deve colocá-la no corpo.

Por quê?

1. servidores proxy têm permissão para modificar cabeçalhos. Muitos estão configurados para remover os cabeçalhos que não conhecem. Isso, no entanto, só se aplica quando você usa HTTP não criptografado. Quando você usa HTTPS, o proxy não pode alterar os cabeçalhos porque eles são criptografados.
2. Quando você usa um serviço da Web, geralmente o faz para interoperabilidade com outros dispositivos, serviços e ferramentas. A maioria das APIs e ferramentas que funcionam com serviços da Web pode alterar facilmente as solicitações, mas muitas dificultam ou até impossibilitam a adição de cabeçalhos personalizados. Obviamente, isso só se aplica quando a interoperabilidade é uma preocupação. Mas quando você não se importa, você pode se perguntar por que está usando serviços da Web em primeiro lugar, em vez de apenas criar seu próprio protocolo no TCP bruto.

Embora a linha esteja um pouco embaçada, para mim uma regra geral é: os dados nos quais sua lógica de negócios trabalha devem estar no corpo, os metadados podem / devem ser colocados em cabeçalhos.

Outra maneira de analisar é: os dados que aparecem apenas em tipos específicos de solicitações devem estar no corpo, enquanto os dados que são tratados de forma consistente em todo o aplicativo devem entrar em cabeçalhos.

Outro ponto de vista é: você pode imaginar que um dado é tratado globalmente, por exemplo, por um roteador / firewall e não por seu aplicativo? Se sim, provavelmente deve aparecer nos cabeçalhos e não no corpo.

Alguns exemplos de aplicação dessas regras seriam:

• As credenciais de segurança entram nos cabeçalhos, pois provavelmente serão tratadas da mesma forma em todos os locais de um aplicativo; no nível da implementação, provavelmente haverá alguns filtros de solicitação que rejeitam solicitações sem credenciais válidas, independentemente do ponto de extremidade real que lida com a solicitação, caso ela passe pelo filtro.
• Se, por outro lado, você tiver um nó de extremidade que permita que um administrador adicione usuários ao seu sistema, o login do usuário a ser criado deverá estar no corpo da solicitação, pois: a) ele é tratado pela lógica de negócios de seu aplicativo; b) aparece nesse endpoint específico, mas não em outros.
• As opções que controlam o armazenamento em cache podem se encaixar nos cabeçalhos (a menos que o armazenamento em cache seja uma parte essencial da lógica de negócios do seu aplicativo).

Voltando à sua pergunta sobre o ID exclusivo do dispositivo: se for usado de maneira consistente em qualquer lugar, por exemplo, apenas para registro, poderá ser colocado nos cabeçalhos. Mas se for usado para filtrar solicitações de maneiras diferentes, dependendo do ponto de extremidade, seria melhor no corpo. Obviamente, se você tiver os dois casos de uso, provavelmente será melhor seguir apenas uma maneira de transmiti-los (provavelmente os cabeçalhos), em vez de forçar o usuário da API a colocar os mesmos dados em dois lugares, fornecendo o dilema de permitir entradas inconsistentes ou implementação de algum tipo de validação.

O conteúdo da solicitação do cliente; as que não serão alteradas em várias solicitações para o mesmo servidor farão parte do HEADER, por exemplo, credenciais; outras que são frequentemente alteradas por solicitação farão parte do BODY.

OU

A propriedade do conteúdo da mensagem / corpo entrará no cabeçalho. por exemplo) tipo de codificação, comprimento do conteúdo, tipo de conteúdo.

E

No seu caso, parâmetros de filtro como devem ser adicionados como parâmetros de consulta / solicitação no URL.

/mobiles?type=MOTO&colour=black

Em serviços repousantes, o próprio URL se refere a um objeto

/conferences/{conference_id} -> refere-se a conferência específica