API REST: intestazioni HTTP personalizzate e parametri URL

Quando usi intestazioni HTTP personalizzate nella parte richiesta di un'API REST?

Esempio:

Useresti mai

GET /orders/view 
(custom HTTP header) CLIENT_ID: 23

invece di

GET /orders/view/client_id/23 or 
GET /orders/view/?client_id=23

L'URL indica la risorsa stessa. Un "client" è una risorsa su cui è possibile agire, quindi dovrebbe far parte dell'URL di base: /orders/view/client/23 .

I parametri sono proprio questo, per parametrizzare l'accesso alla risorsa. Questo avviene in particolare in gioco con i messaggi e le ricerche: /orders/find?q=blahblah&sort=foo. C'è una linea sottile tra parametri e sotto-risorse: /orders/view/client/23/active versus /orders/view/client/23?show=active . Raccomando lo stile della risorsa secondaria e i parametri di riserva per le ricerche.

Poiché ogni endpoint RAPPRESENTA un trasferimento di stato (per alterare il mnemonico), le intestazioni personalizzate dovrebbero essere utilizzate solo per cose che non coinvolgono direttamente il nome della risorsa (l'URL), lo stato della risorsa (il corpo) o i parametri influenzare la risorsa (parametri). Ciò lascia veri metadati sulla richiesta di intestazioni personalizzate.

HTTP ha una selezione molto ampia di intestazioni che coprono quasi tutto ciò di cui hai bisogno. Dove ho visto apparire le intestazioni personalizzate è in una richiesta da sistema a sistema che opera per conto di un utente. Il sistema proxy convaliderà l'utente e aggiungerà " X-User: userid" alle intestazioni e utilizzerà le credenziali di sistema per raggiungere l'endpoint. Il sistema ricevente convalida che le credenziali di sistema siano autorizzate ad agire per conto dell'utente, quindi convalida che l'utente sia autorizzato a eseguire l'azione.

Le intestazioni personalizzate hanno i seguenti vantaggi:

• Può essere letto facilmente da strumenti / script di rete (autenticazione, meta informazioni, ...)
• Mantiene gli URL liberi da materiale di sicurezza (più sicuro, non nelle cache del browser / proxy)
• Mantiene gli URL più puliti: consente una migliore memorizzazione nella cache delle risorse

Vorrei utilizzare un'intestazione personalizzata solo quando non c'è altro modo per passare le informazioni per standard o convenzione. Darren102 sta spiegando il modo tipico per passare quel valore. La tua API sarà molto più amichevole utilizzando modelli tipici rispetto a intestazioni personalizzate. Questo non vuol dire che non avrai il caso di usarli, ma solo che dovrebbero essere l'ultima risorsa e qualcosa non già gestito dalle specifiche HTTP.

Quando usi ... intestazioni HTTP nella parte richiesta di un'API REST?

Autenticazione: GUID, autenticazione di base, token personalizzati, ecc. Ad esempio, autenticazione di base con un token Guid per API REST invece di nome utente / password

Se vieni coinvolto nel passaggio di token o altre informazioni simili all'autenticazione tra domini coperti da PCI-DSS o altre regole di sicurezza, potresti anche dover seppellire i parametri perché alcune normative richiedono esplicitamente che gli elementi di autenticazione rimangano fuori dagli URL che potrebbero essere riprodotti banalmente (da cronologie del browser, registri proxy, ecc.).

Non esiste uno standard per REST, tuttavia il modo accettato sarebbe

GET /orders/view/23

Non si usano le intestazioni personalizzate e quindi la vista 23 after assume essere l'id, quindi avresti una funzione che accetta l'id e quindi produce solo quell'informazione.

Non userei intestazioni personalizzate perché non sai se i proxy li trasmetteranno. Basato su URL è la strada da percorrere.

GET / ordini / visualizza / cliente / 23

Decisamente OK:

GET /orders/view/client_id/23 or 
GET /orders/view/?client_id=23

Anche OK:

GET /orders/view/23 or 

Penso che anche questo andrebbe bene:

POST /orders/view 
(custom HTTP header) CLIENT_ID: 23

È possibile utilizzare intestazioni personalizzate per includere ulteriori informazioni su una richiesta parzialmente elaborata, considerando che l' involucro non è una buona pratica. Le intestazioni sono protette .