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

Quando le informazioni sono importanti, dovresti inserirle nel corpo.

Perché?

1. i server proxy possono modificare le intestazioni. Molti sono configurati per rimuovere qualsiasi intestazione 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 il tuo protocollo su TCP non elaborato.

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

Un altro modo di guardarlo è: i dati che appaiono solo in specifici tipi di richieste dovrebbero essere nel corpo mentre i dati che vengono gestiti in modo coerente nell'intera applicazione dovrebbero andare nelle intestazioni.

Un altro punto di vista è: puoi immaginare che una parte di dati venga gestita globalmente, ad es. da un router / firewall piuttosto che dalla tua applicazione? Se sì, dovrebbe probabilmente andare nelle intestazioni piuttosto che nel corpo.

Alcuni esempi di applicazione di queste regole potrebbero essere:

• Le credenziali di sicurezza entrano nelle intestazioni poiché molto probabilmente verranno gestite allo stesso modo in tutti i punti di un'applicazione; a livello di implementazione ci saranno probabilmente alcune richieste di rifiuto del filtro di richieste senza credenziali valide a prescindere dall'endpoint reale che gestisce la richiesta nel caso in cui attraversi il filtro.
• Se, d'altra parte, si dispone di un endpoint che consente ad un amministratore di aggiungere utenti al proprio sistema, il login dell'utente da creare deve essere nel corpo della richiesta poiché: a) viene 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 perfettamente 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 dispositivo univoco: se viene utilizzato in modo coerente ovunque, ad es. solo per la registrazione, può essere inserito nelle intestazioni. Ma se è usato per filtrare le richieste in modi diversi a seconda dell'endpoint, sarebbe meglio che fosse nel corpo. Ovviamente, se si hanno entrambi i casi d'uso, è probabilmente meglio attenersi a un solo modo di passarlo (probabilmente le intestazioni) piuttosto che forzare l'utente API a mettere gli stessi dati in due punti, dando il dilemma di consentire input inconsistenti o implementazione di qualche tipo di convalida.

Il contenuto della richiesta del cliente; che non verrà modificato tra più richieste allo stesso server farà parte di HEADER, ad es. le credenziali, altre che sono frequentemente modifiche per richiesta faranno parte di BODY.

o

del messaggio / del contenuto del corpo andrà nell'intestazione. e.g) tipo di codifica, lunghezza del contenuto, tipo di contenuto.

E

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

/mobiles?type=MOTO&colour=black

Nei servizi di riposo l'url stesso farà riferimento a un oggetto

/conferences/{conference_id} - > fa riferimento a una conferenza specifica