Cosa appartiene a un'intestazione di richiesta HTTP rispetto al corpo della richiesta?

Sto lavorando a una serie di servizi Web per un client mobile e i requisiti richiedono che un ID dispositivo univoco sia incluso in tutte le richieste, sia archiviato in determinate richieste sia utilizzato per filtrare i risultati in altri.

È stato suggerito di inserirlo in un'intestazione HTTP personalizzata poiché verrà incluso in tutte le richieste, quindi ho iniziato a chiedermi quali criteri potrebbero essere utilizzati per determinare se un determinato dato appartiene a un'intestazione o insieme ad altri dati in l'organismo di richiesta.

Esistono tali criteri?

Quando le informazioni sono importanti, dovresti inserirle nel corpo.

Perché?

1. i server proxy sono autorizzati a modificare le intestazioni. Molti sono configurati per eliminare tutte le intestazioni che non conoscono. Questo, tuttavia, si applica solo quando si utilizza HTTP non crittografato. Quando si utilizza HTTPS, il proxy non può modificare le intestazioni perché sono crittografate.
2. Quando si utilizza un servizio Web, di solito lo si fa per l'interoperabilità con altri dispositivi, servizi e strumenti. La maggior parte delle API e degli strumenti che funzionano con i servizi Web possono facilmente modificare le richieste, ma molte rendono difficile o addirittura impossibile aggiungere intestazioni personalizzate. Questo, ovviamente, si applica solo quando l'interoperabilità è una preoccupazione. Ma quando non ti interessa, potresti chiederti perché stai utilizzando i servizi Web in primo luogo invece di creare semplicemente il tuo protocollo su TCP grezzo.

Mentre la linea è un po 'sfocata, per me una regola empirica è: i dati su cui lavora la tua logica aziendale dovrebbero essere nel corpo, i metadati possono / dovrebbero essere inseriti nelle intestazioni.

Un altro modo di vederlo è: i dati che appaiono solo in tipi specifici di richieste dovrebbero essere nel corpo mentre i dati che sono gestiti in modo coerente in tutta l'applicazione dovrebbero andare nelle intestazioni.

Un altro punto di vista è: puoi immaginare che un dato sia gestito a livello globale, ad esempio da un router / firewall piuttosto che dalla tua applicazione? Se sì, probabilmente dovrebbe andare nelle intestazioni piuttosto che nel corpo.

Alcuni esempi di applicazione di queste regole sarebbero:

• Le credenziali di sicurezza rientrano nelle intestazioni poiché molto probabilmente saranno gestite allo stesso modo in tutti i luoghi di un'applicazione; a livello di implementazione ci sarà probabilmente un filtro di richiesta che rifiuta le richieste senza credenziali valide indipendentemente dall'endpoint effettivo che gestisce la richiesta nel caso in cui attraversi il filtro.
• Se, d'altra parte, si dispone di un endpoint che consente a un amministratore di aggiungere utenti al proprio sistema, il login dell'utente da creare dovrebbe essere nel corpo della richiesta poiché: a) è gestito dalla logica aziendale dell'applicazione, b) appare in questo particolare endpoint ma non in altri.
• Le opzioni che controllano la memorizzazione nella cache potrebbero adattarsi alle intestazioni (a meno che la memorizzazione nella cache non sia una parte fondamentale della logica aziendale dell'applicazione).

Tornando alla tua domanda sull'ID univoco del dispositivo: se viene utilizzato in modo coerente ovunque, ad esempio solo per la registrazione, può essere inserito nelle intestazioni. Ma se viene utilizzato per filtrare le richieste in modi diversi a seconda dell'endpoint, sarebbe meglio nel corpo. Naturalmente se hai entrambi i casi d'uso, probabilmente è meglio attenersi a un solo modo di passarli (probabilmente le intestazioni) piuttosto che forzare l'utente API a mettere gli stessi dati in due punti, dandoti il ​​dilemma di consentire input incoerenti o implementazione di un qualche tipo di validazione.

Il contenuto della richiesta del cliente; che non verranno modificati su più richieste allo stesso server farà parte di HEADER, ad esempio credenziali, altri che sono spesso modifiche per richiesta faranno parte di BODY.

O

la proprietà del contenuto del messaggio / corpo andrà nell'intestazione. es.) tipo di codifica, lunghezza del contenuto, tipo di contenuto.

E

Nel tuo caso, i parametri di filtro simili dovrebbero essere aggiunti come parametri di query / richiesta nell'URL.

/mobiles?type=MOTO&colour=black

Nei servizi riposanti l'URL stesso farà riferimento a un oggetto

/conferences/{conference_id} -> indica una conferenza specifica