Timeline for How do searches fit into a RESTful interface?
Current License: CC BY-SA 3.0
24 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 3, 2022 at 16:41 | comment | added | emeraldhieu | I don't think b) is a good solution because you have to create filter data whenever you search something, meaning "POST /filters" then "GET /search?filterId=abc". From REST API's user perspective, it's really cumbersome. Regarding a), I don't think you can implement a complicated filter without using nested structure via POST such as (AND ( a, OR (b, c)). This complex filter can't be expressed nicely by URL without encoding the special characters. The URL will probably exceed the limit. I agree with @JensG, it seems like REST API convention introduces more problems than solutions. | |
| Aug 21, 2020 at 17:58 | comment | added | Grault | @J.Allen Trim the query on the client so it's short enough, put the remainder in a cookie, and explain the situation on the results page. | |
| Nov 21, 2019 at 21:51 | comment | added | J. Allen | Can we differentiate between a search query with known number of possible static parameters, and a query that accepts a list as a parameter? Assuming you want to support browsers as possible clients, a list can quickly exceed 2000 characters. It seems wrong to provide an API that might randomly fail just because the user or user's script gets too greedy. If committed to a GET, the best solution I suppose would be for the client to break up their query into multiple queries if they detected themselves going over threshold, and have that expectation as part of the API. | |
| Aug 13, 2019 at 14:34 | comment | added | AndreiMotinga | @p1100i, thanks for the response. Could you please provide any resources on to how to approach building something similar to you google linked example. I'm looking for this kind of "scheme" I could use to construct complex queries. some sort of "url language". | |
| Jan 31, 2019 at 2:36 | comment | added | Lie Ryan | 2000 characters is the limit for browsers and browser based applications. If you're creating a Web APIs, you're not necessarily constrained by the URL length limit, as HTTP spec doesn't specify any URL length limits. | |
| Apr 22, 2017 at 23:33 | comment | added | phil294 | what if it gets really messy with filters like x between y and z? | |
| Feb 15, 2017 at 3:07 | comment | added | Jasmijn | "GET request should not modify anything inside your application (idempotent)" while GET is idempotent, the relevant word is "safe" here. Idempotent means that doing GET on a resource twice is the same as doing GET on that resource once. PUT is also idempotent, but not safe, for example. | |
| Sep 9, 2016 at 6:08 | history | edited | p1100i | CC BY-SA 3.0 | not sure how to revert edits, so imma just edit that last change - which I don't like - back |
| S Sep 8, 2016 at 16:37 | history | suggested | CommunityBot | CC BY-SA 3.0 | corrected GET idempotent/safe and remark that a resource should always expose an entity (noun), never an action (verb) |
| Sep 8, 2016 at 14:03 | review | Suggested edits | |||
| S Sep 8, 2016 at 16:37 | |||||
| Apr 12, 2014 at 5:48 | vote | accept | Rob Baillie | ||
| Mar 27, 2014 at 16:47 | comment | added | JensG | Why am I getting the impression that REST is quite often part of the problem, rather than part of the solution? | |
| Mar 27, 2014 at 16:10 | history | edited | p1100i | CC BY-SA 3.0 | Better formatting |
| Mar 21, 2014 at 15:27 | history | edited | p1100i | CC BY-SA 3.0 | added 1 characters in body |
| Mar 21, 2014 at 15:25 | comment | added | p1100i | @RobBaillie right, even if not saving it, it's a good choice so you can test it through | |
| Mar 21, 2014 at 14:19 | comment | added | Rob Baillie | I tend to agree. I still think it's a bit of a stretch to state that you are "creating a job search", but I'm worried that I have no other option than to live with that (though probably not actually save it) | |
| Mar 21, 2014 at 13:56 | history | edited | p1100i | CC BY-SA 3.0 | added 162 characters in body |
| Mar 21, 2014 at 13:52 | comment | added | p1100i | @RobBaillie yes it is, I just don't like nested routes ;] they're evil! | |
| Mar 21, 2014 at 13:31 | comment | added | Rob Baillie | In point b, is this a simple variation of my own reference to a POST to domain/Jobs/Search/, maybe with domain/JobsSearch/ instead, or did you mean something different? Can you clarify? | |
| Mar 21, 2014 at 13:23 | comment | added | p1100i | @RobBaillie Ye the browser was just a use case. I wanted to express the fact that your search as a whole is represented by a URL string. Which has a lot of comfort in usability along with other points later in the answer. | |
| Mar 21, 2014 at 13:20 | history | edited | p1100i | CC BY-SA 3.0 | added 91 characters in body |
| Mar 21, 2014 at 13:02 | comment | added | Rob Baillie | For clarification, this question is intended to be about web-services design, not web-site design. So whilst the browser behaviour is of interest in the wider scope of the question's interpretation, in the particular case described it's of no consequence. (interesting point though). | |
| Mar 21, 2014 at 12:50 | history | edited | p1100i | CC BY-SA 3.0 | added 235 characters in body |
| Mar 21, 2014 at 12:44 | history | answered | p1100i | CC BY-SA 3.0 |