Timeline for How do searches fit into a RESTful interface?
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 5, 2015 at 17:20 | comment | added | stevendesu | You can overcome the need to store filters by simply... not storing them. Nothing about REST guarantees that it is persistent. You might make a request for GET /jobs/37 and receive a result, then someone deletes the resource and 2 seconds later the same request returns a 404. Similarly if you POST /searches and you're redirected to a search result (the search is created and you receive a 201 with Location header to the resource), 2 seconds later that result may be wiped from memory and have to be regenerated. No need for long-term storage. | |
| Mar 29, 2014 at 14:34 | comment | added | pgraham | Obviously, query parameters are the best solution, but your question specifically asks about how to deal with filter definitions longer than the limit on URLs imposed by some servers. In order to work around length limit you will either need to compress the query string somehow or you need to use a request method which supports specifying a body of arbitrary length. If you don't want to treat filters as a resource, just support a non-restful interface where filter definitions are POSTed. You will lose cacheability, but if you're data is volatile enough it wouldn't benefit from caching anyway. | |
| Mar 28, 2014 at 9:40 | comment | added | Rob Baillie | My first reaction to this is that whilst it's good information, it's really just a variation on the answer provided by @burninggramma. Essentially it is "create a new entity called filter / search, call to create it and then call to retrieve it". The variation being that the call to retrieve it is more like a call to apply it to a collection. Interesting. However both your and burninggramma's answer suffer from the same problem - I have no desire to create the filters. There will be a huge number of them, and they don't need to be stored except in order to keep a RESTful implementation. | |
| Mar 27, 2014 at 14:39 | history | edited | pgraham | CC BY-SA 3.0 | Edited to mention that a 303 status code for redirecting to a filtered jobs collection might be preferable to a 302. |
| Mar 27, 2014 at 14:30 | history | answered | pgraham | CC BY-SA 3.0 |