I am trying to figure out if I should fight against this policy.
Cambia la tua organizzazione o cambia la tua organizzazione.
La politica sembra molto sbagliata, in un contesto generale . Potrebbe avere senso date le circostanze. Non vorrei mai sostenere quelle pratiche in un sistema in fase di costruzione da zero, ma potrebbe essere una soluzione pratica dati i vincoli locali.
Fielding ha scritto nel 2008
REST is intended for long-lived network-based applications that span multiple organizations. If you don’t see a need for the constraints, then don’t use them.
REST è stato progettato per la creazione di applicazioni su scala web; per esempio, il world wide web. Una parte importante di questo progetto era prestare attenzione ai componenti generici e sapere cosa potevano sapere sui messaggi che venivano trasmessi. Le intestazioni HTTP sono effettivamente metadati in modo che i componenti generici sappiano cosa sta succedendo. Questo a sua volta offre varie ottimizzazioni come il caching.
Il che significa che se non si inseriscono le informazioni di autenticazione nel messaggio in cui si aspettano i componenti generici, non vedranno tali informazioni e non reagiranno in modo appropriato.
Vedi RFC 7234, Memorizzazione di risposte a richieste autenticate .
Ora, questo argomento in particolare è un po 'più debole di vent'anni fa, perché probabilmente utilizzeremo una connessione crittografata per scambiare i messaggi. In tali circostanze, le capacità degli intermediari sono meno preoccupanti, perché non dovrebbero essere comunque in grado di leggere i messaggi.
For POST and PUT methods, the auth string was accepted in the message body. For GET and DELETE methods, it was in the URL query. This seems wrong to me, but I can't exactly explain why.
In senso stretto, l'incorporamento dei dati di autenticazione nel payload di una richiesta PUT è semanticamente errato
The PUT method requests that the state of the target resource be created or replaced with the state defined by the representation enclosed in the request message payload.
A meno che l'obiettivo non sia includere le informazioni di autenticazione nella rappresentazione aggiornata della risorsa, non ci appartiene.
Mettere le credenziali di autenticazione nella parte di query dell'URI nella richiesta è "errato" perché l'URI è un identificatore - /foo/bar?user=alice è una risorsa diversa da /foo/bar?user=bob . Il fatto che queste due risorse abbiano sempre la stessa rappresentazione e che l'eliminazione di una ne cancella necessariamente l'altra, è un dettaglio di implementazione che non è visibile all'esterno del server.
Mi sembra che il tuo team non stia cercando di fare REST, ma sta invece implementando un protocollo RPC usando HTTP come trasporto per i messaggi. Che va bene se non hanno bisogno delle proprietà di ridimensionamento protette dallo stile architettonico REST.
Is there a valid alternative to HTTP headers for sending auth credentials
I certificati client sarebbero un altro approccio; vale a dire, il client e il server negoziano una connessione crittografata e il server sa chi è il client perché le risposte fornite dal client sono coerenti con la chiave pubblica nota del client (il che implica che il client abbia accesso alla chiave privata) .
(Non c'è davvero niente di sbagliato nel mettere le credenziali di autenticazione nel corpo del POST. POST è così generico non importa, le componenti intermedie non sono in grado di trarre molte conclusioni quando la semantica è specificata in modo approssimativo, ma è un po 'maldestro, immagina una pagina web in cui ogni link è stato sostituito con un modulo. / p>