Chiamare un servizio RESTful con * molti * parametri

Question

NOI stiamo progettando un'app per iPhone che richiamerà un servizio RESTful in esecuzione in Tomcat. Abbiamo bisogno di inviare molti parametri di ricerca e abbiamo superato il limite massimo consentito dal telefono.

Sarebbe RESTful utilizzare una chiamata PUT con i parametri nel corpo, anche se l'intento non è quello di modificare il server? Un POST non sembra corretto perché non è idempotente, mentre un PUT è (e quindi ricorda più da vicino il comportamento o di un GET).

Grazie.

Answer 1

Se lo si desidera RESTful, è possibile procedere in questo modo: PUT i parametri sul server (in una posizione di propria scelta), oppure è possibile POSTli e lasciare che il server li posiziona per voi. In entrambi i casi, hai appena creato una risorsa che contiene i parametri necessari. Quindi si invia un GET riferendosi a quella particolare risorsa. Rispondendo al tuo GET, il server quindi sa dove ottenere il suo ampio set di parametri. Quello sarebbe RESTful.

Detto questo, tuttavia, l'invio di due richieste non è molto efficiente, se è possibile fare la stessa cosa con una singola richiesta. Vorrei solo provare a essere pragmatico.

Considerate questo: PUT dice proxy che non dovrebbero in cache la risposta, ma un nuovo tentativo (da alcun elemento di infrastrutture lungo la linea) è sicuramente possibile, dal momento che è idempotente (proprio come GET). Cosa ti dà GET oltre PUT? La risposta può essere memorizzata nella cache. Ma con quel gran numero di parametri, suppongo che la maggior parte delle richieste sarà comunque unica, giusto? Di conseguenza, la memorizzazione nella cache non è molto redditizia. Pertanto, l'uso di PUT sembra essere il pragmatico e quindi la scelta corretta.

Answer 2

Violare lo spirito di REST, ma se funziona, sii pragmatico.

Answer 3

avete tre opzioni che sono massimamente conforme con http:

In primo luogo, si ha la possibilità di inviare le vostre params compressi in qualche modo a formare un URL più breve.

In secondo luogo, non c'è niente di GET che dice che non è possibile inviare un messaggio-corpo nella richiesta, in qualunque Content-Type o -Length si sceglie. Non tutti i server supportano questo, ma lo stesso protocollo HTTP.

In terzo luogo, si possono inviare i parametri a una risorsa /queries/, e hanno che rispondono con 201 Created e un nuovo URL (come /queries/78a65g82) nell'intestazione Location risposta, che il cliente quindi chiama GET su (più volte, o anche in Ranges , se questo è un vantaggio) per recuperare il risultato.