Vorrei implementare un servizio REST che sia in grado di analizzare query come il recupero degli utenti creati dopo startdate e prima di endate e con il privilegio di admin. Sembra che l'implementazione REST standard possa richiedere solo ID. Ho bisogno di un protocollo auto-definito per rendere possibile questo tipo di query o qualsiasi standard?Cosa succede se voglio implementare una query complicata in REST
Grazie!
Date un'occhiata a Google's GDATA Protocol. È molto RESTful e hanno un modo molto piacevole di eseguire query "complesse" pur mantenendo un URI pulito.
http://code.google.com/apis/gdata/docs/2.0/reference.html#Queries
Ecco un esempio di ciò che la loro interrogazione pulita URI
http://example.com/jo/-/Fritz/2006
invece di
http://example.com/jo?category=Fritz&category=2006
Da Google:
Questo approccio identifica una risorsa senza u canta i parametri di query e produce URI più puliti. Abbiamo scelto questo approccio per le categorie perché pensiamo che le query di categoria saranno le query più comuni.
Per quanto mi riguarda, le cose restful sono valide per le azioni CRUD. È possibile implementare il metodo/url separato search e passarlo come molti parametri necessari. E se provi ancora ad aderire alle metodologie REST, dovresti utilizzare il tipo di richiesta GET.
> le cose restful sono valide per le azioni CRUD - non è vero. – TheWhiteRabbit
@TechExchange hai ragione. La mia conoscenza del REST è cambiata da quando ho risposto a questa domanda.) – Eimantas
Non esiste alcun vincolo in REST che indica che è possibile eseguire query solo per ID. Non c'è assolutamente nulla di sbagliato nell'usare un insieme di parametri di query per restituire un insieme di utenti che corrispondono a quei criteri di ricerca.
Ryan Bates ha un Railscast in cui mostra la creazione di ricerche come risorsa. Il concetto è ancora valido, anche se non stai facendo Rails.
Prendo la semantica delle ricerche sul campo di django come linee guida per ricerche complesse. https://docs.djangoproject.com/en/dev/ref/models/querysets/#id4
Non essere sviato dal fatto che è definito come un'API specifica della lingua, è facile da tradurre in parametri di query html.
Un esempio potrebbe essere http://example.com/Goods?category=fruit&size__lt=14
per ottenere il risultato di select * from goods where category = 'fruit' and size < 14 in SQL o /goods[@category='fruit' and @size < 14] in XPath, o qualsiasi altra cosa.
Penso che sia un bel modo, ma non può soddisfare tutte le situazioni. –
Vero. Ma ti mette nella giusta mentalità. Gli URI dovrebbero essere pensati come ID e non come query. Non pensare alla tua query in termini di stringa di ricerca o SQL, ma considerala come un ID che identifica una risorsa (che a sua volta è composta da altre risorse - il collegamento ipertestuale è un grosso problema in REST). – nategood
Mi permetto di dissentire.Una * query string * in un URI è esattamente allo scopo di interrogare. Non rende invalido l'approccio dell'URI per query, al contrario, può avere vantaggi, specialmente attorno alla memorizzazione nella cache. Quindi esegue il POST di una query complessa ed emette un reindirizzamento. Tutto dipende dalle vostre esigenze e nessuna delle soluzioni è intrinsecamente scostante. – SerialSeb