Ho un URL per andare a prendere gli appuntamenti per un utente in questo modo:Passando array in GET per una chiamata REST
/user/:userId/appointments
Come dovrebbe l'url simile se voglio ottenere appuntamenti per più utenti?
dovrebbe essere:
/appointments?users=1d1,1d2..
Grazie, Chris.
Le raccolte sono una risorsa così/gli appuntamenti vanno bene come risorsa.
Le raccolte di solito offrono anche filtri tramite la querystring che è essenzialmente ciò che user = id1, id2 ... è.
Quindi,
/appointments?users=id1,id2
va bene come una risorsa RESTful filtrato.
/appointments?users=1d1,1d2..
va bene. È praticamente la tua unica opzione sensata dal momento che non puoi passare in un corpo con un GET.
Penso che sia una pratica migliore per serializzare i tuoi parametri di chiamata REST, di solito da loro JSON-Encoding:
/appointments?users=[id1,id2]
o anche:
/appointments?params={users:[id1,id2]}
Quindi è un-codificare sul server . Questo ti darà più flessibilità a lungo termine.
Assicurati di URLEncode anche i parametri prima di inviarli!
Invece di utilizzare http GET, utilizzare http POST. E JSON. Oppure XML
Ecco come sarà il flusso di richieste al server.
POST /appointments HTTP/1.0
Content-Type: application/json
Content-Length: (calculated by your utility)
{users: [user:{id:id1}, user:{id:id2}]}
O in XML,
POST /appointments HTTP/1.0
Content-Type: application/json
Content-Length: (calculated by your utility)
<users><user id='id1'/><user id='id2'/></users>
si potrebbe certamente continuare a utilizzare GET, come da lei proposto, in quanto è certamente più semplice.
/appointments?users=1d1,1d2
Il che significa che si dovrebbero mantenere le strutture dati molto semplici.
Tuttavia, se/quando la struttura dei dati diventa più complessa, http GET e senza JSON, la programmazione e la capacità di riconoscere i dati diventano molto difficili.
Pertanto, a meno che tu non possa mantenere la struttura dei dati semplice, ti consiglio di adottare un framework per il trasferimento dei dati. Se le tue richieste sono basate su browser, la prassi abituale del settore è JSON. Se le tue richieste sono server-server, XML è il framework più conveniente.
JQuery
Se il client è un browser e non si utilizza GWT, è consigliabile utilizzare jQuery REST. Google su servizi RESTful con jQuery.
Non penso che questo sia il modo corretto per farlo. Stai recuperando una risorsa e non POSTENDO una nuova. –
Non penso che tu abbia capito l'uso di http GET/POST. Non sono conformi al dizionario inglese che significa per quelle parole. POST è quando si tenta di ottenere GET ma con gli argomenti non posizionati non nell'url ma nel flusso io. –
È molto imbarazzante avere qualcuno con una comprensione inadeguata del metodo POST, ma a seconda del significato del dizionario inglese, votarmi. Non puoi biasimarmi per le decisioni sintattiche prese dalle persone che hanno scelto di definirlo in quel modo. Non uccidere il messaggero. –
Un altro modo per farlo, che può avere senso in base all'architettura del server o al framework scelto, è ripetere lo stesso argomento più e più volte. Qualcosa di simile a questo:
/appointments?users=id1&users=id2
In questo caso vi consiglio di usare il nome del parametro in singolare:
/appointments?user=id1&user=id2
Questo è supportato nativamente da quadri come Jersey (per Java). Dai un'occhiata a this question per maggiori dettagli.
? {Users: [id1, id2]} non segue le convenzioni dei parametri di querystring di? Key1 = val2 & key2 = val2. – bryanmac
buona presa! modifica per correggere ... – sgress454
Inoltre, hai un esempio di servizi principali che offrono oggetti serializzati in filtri di querystring? Da quello che ho visto di più offrono semplici filtri di opzioni delimitate da virgole o formati di query come OData – bryanmac