Supporto di un servizio RESTful - Devo usare Pragma, i cookie, un'intestazione personalizzata o qualcos'altro per identificare le sessioni e le transazioni dei clienti?

Question

Stiamo costruendo una SOA con un approccio RESTful ai servizi. Una volta che i sistemi sono in produzione, avremo molti clienti che utilizzano l'interfaccia, inclusi i sistemi interni e di terze parti.

Vorremmo essere in grado di consumare e eco nelle informazioni risposta data dal un'applicazione client come: -

• Session ID - Potrebbe essere un Java EE ID di sessione o cliente qualcosa di specifico, questo è utile per il team di supporto e il debug dei problemi del client per rintracciarli attraverso tutti i nostri sistemi.
• ID transazione - Un identificatore univoco per la richiesta che possiamo eco al client per aiutare il cliente in correlazione richiesta/risposta se essi invocano il servizio in modo asincrono o se implementiamo un processo di lunga esecuzione 202 stile accettati.

Soluzioni possibili

Così attaccano ai vincoli RESTful suggerirebbero abbiamo bisogno di utilizzare HTTP per implementare questo e ci sono diverse opzioni che potremmo implementare.

• intestazione Pragma - implementare estensione-pragma per la transazione-id, session-id, ecc Questo sembra purista di soluzioni in quanto utilizza un'intestazione HTTP standard, anche se sarei interessato è diventato una discarica per tutto ciò che non può essere disturbato a pensare correttamente.
• X-My-Header - intestazioni personalizzate per ogni campo che richiediamo. Può essere spogliato dai proxy, non HTTP di base quindi sembra anti-resto
• In stringa di query o rappresentazioni XML/JSON - Aggiungere i campi per tutte le nostre risorse. Poiché si tratta di un parametro operativo, sembra che debba essere fornito come metadata anziché su una risorsa.
• Cookies - utilizzare Cookie e Set-Cookie per contenere valori-chiave; utile nel caso di ID di sessione poiché la maggior parte delle implementazioni utilizza già i cookie. Dovrebbe re-inviare ogni volta per supportare la correlazione lato client che tipo di sconfigge il punto di utilizzo di un cookie.

La risposta

C'è un precedente per questo? Siamo pazzi? C'è qualcosa di ovvio che mi manca in tutte le mie ricerche? A nessuno importa davvero come sosterranno i loro servizi una volta che saranno schierati? Devo solo stare zitto e andare via?

Sto sperando che qualcuno possa aiutare.

P.S. scusa se questo è un po 'un saggio, il consiglio ha detto "essere specifico" ....

Answer 1

Oh, questo è un dolore. Ci sono stato anche io.

Bene, l'idea con i metadati per le transazioni, le sessioni ecc. È una buona idea. Per la registrazione, almeno.

Il problema è impostare qualcosa che sia compatibile con le varie politiche aziendali e l'infrastruttura SOA.

Esiste uno scambio tra il miglior design e la massima interoperabilità nel caso di HTTP.

Il percorso sicuro consiste nel codificare i metadati nel messaggio stesso. Non molto bello, e una tale soluzione finisce per sembrare un po 'come SOAP dove hai una busta con le intestazioni per tutti i messaggi.

Ho finito per utilizzare un X-header per informazioni come l'ID della transazione. Tuttavia, come hai detto, i proxy/b2b-gateways ecc potrebbero rimuovere le intestazioni, non è ovvio che tu possa recuperarli con tutti i framework di sviluppo nominati, le applicazioni COTS ecc. Quindi se fai così, dovresti evitare di rendere i metadati obbligatori per ottenere una soluzione in esecuzione - solo "bello avere".

I biscotti non sono altro che dolore. Potrebbero essere fastidiosi o talvolta utili anche con l'interazione del browser, ma in uno scenario SOA, sarà una cattiva idea. Molte cose possono andare storte ed è un problema mettere a punto le organizzazioni incrociate.

Eviterei anche l'utilizzo di stringhe di query insieme ai dati POST o PUT. È possibile in base alle specifiche HTTP. ma non quando si tratta di implementazione in un framework casuale.

Answer 2

È possibile utilizzare un GUID e consentire al client di generarlo e passarlo come parte di qualsiasi richiesta che avvia il flusso di lavoro/processo aziendale. Questo GUID può essere utilizzato per correlare tra più componenti che partecipano al flusso di lavoro.