Progettazione del metodo POST REST: parametri di query / modulo e messaggi di contenuto incapsulati

Naviga le tue risposte
1

Sto progettando un REST API e ho affrontato una scelta di formattazione dei miei metodi POST per l'assorbimento dei parametri in forma libera tramite stringa di query o parametri di contenuto: 

POST /my/api HTTP/1.0

paramOne=XYZ&paramTwo=ABC

o si aspetti che venga inviato un messaggio di dati formattato in modo rigido (XML / JSON) che incapsula i parametri: 

POST /my/api HTTP/1.0

<requestClass>
    <paramOne>XYZ</paramOne>
    <paramTwo>ABC</paramTwo>
</requestClass>

Ho una preferenza per il secondo approccio perché è più pulito (ovvero un singolo argomento di input a livello di codice rispetto a uno multiplo, oltre alla convalida del formato di base) ed è anche più adatto alla gerarchia dei dati (ad esempio se paramTwo ha avuto entità che, sebbene non siano impossibili, non sarebbero così semplici da implementare nell'approccio del parametro query / form): 

<requestClass>
    <paramOne>XYZ</paramOne>
    <paramTwo>
        <subOne>1</subOne>
        <subTwo>2</subTwo>
    </paramTwo>
</requestClass>

Quindi, la mia domanda è, oltre alle preferenze di stile, ci sono altre considerazioni nel decidere se un metodo REST POST debba prendere i parametri o un singolo messaggio incapsulante? Ci sono delle linee guida di base che si avvicinano all'attuazione a seconda di diversi fattori o ambiente? Ad esempio, un approccio presenta più vulnerabilità di sicurezza rispetto agli altri (ho un accenno non perché sia il contenuto che la stringa di interrogazione possono essere annusati con altrettanta facilità e, nel caso di HTTPS, non importa) ecc. ?

Se ciò è importante, i miei servizi sono scritti in Java e forniti tramite Apache CXF in esecuzione in Tomcat 7 .

    
posta amphibient 22.11.2016 - 23:43
fonte

3 risposte

1

C'è una differenza concreta tra i due.

La lunghezza della stringa di query è severamente limitata (a seconda del browser / server in uso) rispetto alla dimensione massima di una richiesta POST

8000 caratteri potrebbero sembrare molto, ma se invii elenchi di cose con nomi di parametri lunghi, puoi presto esaurire.

Se non hai un numero definito e una lunghezza massima di parametri, dovresti utilizzare il corpo della richiesta

    
risposta data 23.11.2016 - 00:07
fonte
1

Suggerirei di guardare più in generale sia al POST che al GET, con un occhio di coerenza per la tua API, soprattutto dal momento che stai guardando REST.

Vari identificatori delle informazioni desiderate (risorsa) per il GET necessariamente entrano nel percorso o nei parametri di ricerca in quanto non esiste un corpo.

Per gli stessi parametri, farei lo stesso per il POST di GET, quindi l'URI è lo stesso. Altri parametri che non sono condivisi tra GET e POST potrebbero andare in entrambi i modi, e forse nel corpo invece sono a posto dell'URI.

    
risposta data 22.11.2016 - 23:59
fonte
1

Probabilmente non dovresti descrivere la prima opzione come forma libera. Sembra che tu possa dire al tuo cliente di inviare dati usando la application / x-www -form-urlencoded codifica. Questa è la codifica utilizzata dai browser Web durante l'invio dei moduli.

Sia questa che altre codifiche come XML, JSON, ecc. possono funzionare bene, quindi sceglierei quale sembra più conveniente implementare e documentare in modo affidabile. Come dici tu, XML & In genere, JSON funziona meglio di urlencoded form per i dati con una struttura ad albero.

Dovresti essere in grado di trattare la codifica come un singolo input per il tuo codice. Non si dice quale linguaggio di programmazione si sta usando, ma mi aspetterei che qualsiasi linguaggio utilizzato sul web abbia modo di ottenere il corpo della richiesta come una stringa, che dovrebbe essere quindi in grado di eseguire attraverso una funzione di decodifica per qualsiasi formato esso è stato inviato.

    
risposta data 23.11.2016 - 00:08
fonte

Leggi altre domande sui tag

Qual è il modo migliore / più pitonioso di prendere in giro una funzione privata? Come decidere se l'oggetto deve essere passato come parametro o essere un membro della classe