Dovrei inserire il contesto di richiesta nel percorso o nelle intestazioni?

Question

Dovrei inserire il contesto di richiesta nel percorso o nelle intestazioni?

#1 da (3 voti)
#2 da (0 voti)

0

Sto progettando un sistema che

Agire come proxy che chiama un servizio su back-end nel contesto di utente e sua sessione
Gestisci sessioni per utenti su più back-end

Esporrò il sistema su HTTP.

La maggior parte delle richieste avrà bisogno dei parametri ID back-end , user-id e ID-sessione , ora posso modellarla come parametri del percorso

/:back-end-id/:user-id/:session-id/...

O come intestazioni HTTP ( x-agrzes-back-end-id , x-agrzes-session-id , x-agrzes-user-id )

Dove è meglio mettere quei parametri?

Per gli endpoint proxy non li voglio assolutamente nel corpo o nella query poiché voglio inoltrarli come è per il back-end.

L'API verrà utilizzata da server a server.

Il significato della sessione potrebbe essere qualcosa come l'autorizzazione OAuth. Il sistema gestisce l'ottenimento e il rinnovo delle credenziali di accesso e quindi consente in modo trasparente di accedere alle risorse di back-end utilizzando tali credenziali.

Quindi lo scambio di esempio potrebbe apparire come questo

Stabilisci la sessione foo per l'utente bar con il back-end bazz
< OAuth exhacnge gestito e guidato dal sistema >
Chiama il servizio A sul back-end bazz nel contesto dell'utente bar e la sua sessione foo (funziona se la sessione è stabilita e le credenziali sono valide)

L'identificativo di sessione è scelto dal client, quindi per tutti e tre (id di sessione, id utente, id di sessione) sono necessari per trovare la sessione il client non deve memorizzare identificativi di sessione generati, quindi può essere stateless.

api-design http headers path

posta AGrzes 24.10.2018 - 10:31

fonte

2 risposte

Leggi altre domande sui tag api-design http headers path

Rendere l'esecuzione dello script Python infallibile oltre l'aggiunta di shebang Come eseguire in sicurezza una lista per rimuovere in sicurezza un elemento e gli elementi associati

score 3 · Answer 1

Gli URL dovrebbero identificare risorse . Quindi questo dipende dalla semantica delle tue richieste.

Non andrei in nessun modo, ma in mezzo. Senza conoscere i tuoi esatti casi d'uso, direi che backend-id e id-utente sono proprietà della risorsa che stai richiedendo, quindi dovrebbero far parte di l'identificativo della risorsa.

D'altra parte l' session-id è piuttosto una condizione al contorno e non è realmente una proprietà della risorsa. È più di una proprietà della richiesta. La sessione può o non può cambiare, ma la risorsa no, è invariata verso la sessione. Quindi direi che l' session-id non dovrebbe essere una parte dell'identificatore della risorsa, ma piuttosto un'intestazione.

Se user-id non è considerato parte della risorsa, ma piuttosto usato per scopi di autorizzazione (ignorando il fatto che questa potrebbe essere una pessima idea), potrebbe andare meglio nel intestazione e viceversa se l' ID di sessione è considerato parte della risorsa per qualsiasi motivo.

score 0 · Answer 2

Sembra che tu stia cercando di inviare dati di stato tramite un protocollo stateless. destinazione pain !

Nella maggior parte dei casi ci si aspetta che l'ID di sessione sia specifico per l'utente e il back-end. Sarebbe anche generato dal proxy piuttosto che dal client.

Dato questo vorrei che il client avvii la sessione con una richiesta di Open(userid, backendid? (possibly generated by proxy)) e aggiunga l'id della sessione alla risposta come cookie, mantenendo l'ID utente e l'ID backend relativi memorizzati sul proxy.

Il client può quindi inviare il cookie dell'ID di sessione con le sue richieste successive e fare in modo che il proxy estragga l'ID utente e il back-end corrispondenti dal suo archivio interno