Servizi REST, GET e parametri complessi passati nel BODY

di il
3 risposte

Servizi REST, GET e parametri complessi passati nel BODY

Ho il seguente problema ""filosofico"".

Ho un servizio REST, implementata on Java usando Spring (ma questo non e' un problema), e devo fare una ricerca ed ottenere un risultato di dimensioni abbastanza consistenti.

Le regole sui servizi REST dicono che devo usare una GET.

Il problema e' che i parametri di ricerca sono una struttura complessa: in particolare possono contenere liste di "ID" (anche centinaia o migliaia) da usare per accedere al DB (id che sono stati estratti da tutt'altra parte per tutti altri motivi).

Ora, il metodo ""ideale"" sarebbe passare queste informazioni nel BODY.
Spring non ha problemi a configurare un servizio che risponde ad una GET i con i parametri nel BODY.
Postman non ha problemi a chiamare una GET passando i parametri nel BODY.

A quanto sembra, invece Angular questa cosa gli sta particolarmente sulle scatole.
Ed anche altri client REST che ho provato non lo supportano, (ma sono anche client abbastanza ""minimali"")

Non essendo molto esperto di lato client Web (e di Angular, ""fortunatamente"" ), esiste un modo per ovviare a questo inconveniente, magari usando UN'ALTRA libreria Javascript un po' piu' ""smart""?

Non ho ancora trovato un'ESPLICITO DIVIETO (qualche RFC UFFICIALE) ad usare il BODY in una GET.

Il fatto che GENERALMENTE non si fa, NON E' significativo.
Se non si fa PERCHE' le librerie sono sceme e non lo supportano, OK, ma NON E' la motivazione corretta.

3 Risposte

  • Re: Servizi REST, GET e parametri complessi passati nel BODY

    Il fatto che molte librerie e in generale client, proxy e server http non supportano il request body nella GET è un motivo sufficiente per evitare di utilizzarlo.
    La situazione che descrivi è abbastanza frequente ovvero effettuare una ricerca (quindi sola lettura che non crea né modifica nulla) con parametri complessi che rischiano di generare una querystring troppo lunga per una url.
    La soluzione migliore a mio avviso è quella di creare tramite POST una risorsa che rappresenta appunto la tua "Richiesta di Interrogazione", la risorsa sarà un json contenente i due oggetti { searchParameters:{...} , result : {...} }
    Nella POST di creazione imposterai soltanto searchParameters, il server risponde assegnando un UUID a sottintendere che la "Richiesta di Interrogazione" è stata creata e identificata come risorsa autonoma. In seguito farai una GET sulla URL dove vedrai il campo result valorizzato con i risultati.
    Certamente si tratta di fare due chiamate al server invece che una ma in questo modo rispetti la filosofia REST e inoltre presumendo che l'elaborazione richieda anche tempo potrai effettuare l'operazione in background, per esempio potrai aggiungere altri campi come "status": "in pregress" , "estimatedCompleteTime" per indicare al client che il processo è in corso e invitarlo a richiamarti quando sarà stato completato.
    La "Richiesta di Interrogazione" potrà anche essere effimera, puoi tenerla in memoria (primaria o secondaria) anche solo pochi minuti poiché presumi che il client leggerà presto il risultato e non ne avrà più bisogno.
  • Re: Servizi REST, GET e parametri complessi passati nel BODY

    migliorabile ha scritto:


    Le regole sui servizi REST dicono che devo usare una GET.

    Il problema e' che i parametri di ricerca sono una struttura complessa: in particolare possono contenere liste di "ID" (anche centinaia o migliaia) da usare per accedere al DB (id che sono stati estratti da tutt'altra parte per tutti altri motivi).
    Mi pare di ricordare (sono certo di averlo letto su risorse autorevoli) che in caso di ricerche "complesse" (cioè con una quantità elevata di parametri e/o con struttura complessa), è accettabile in REST fare un POST per tale ricerca.
  • Re: Servizi REST, GET e parametri complessi passati nel BODY

    L'uso del POST era sottointeso
    L'uso della "doppia"" interrogazione l'avevo immaginata
    Se po' fa
    E mi risolve anche il problema delle query che ritornano un sacco di risultati
    Se po' fa
Devi accedere o registrarti per scrivere nel forum
3 risposte