Timeline for How do searches fit into a RESTful interface?
Current License: CC BY-SA 3.0
30 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 14, 2024 at 4:53 | comment | added | Daniel Kaplan | Related: stackoverflow.com/questions/9234363/… This is a useful resource (pun unintended): rfc-editor.org/rfc/rfc7231#section-4.2.2 | |
| Feb 11, 2020 at 12:42 | comment | added | Ferran Maylinch | I would not follow RESTful strictly, especially if you're calling the endpoints from javascript. I posted a related answer here about using only POST just to forget about the http-methods and focusing on the method names. | |
| May 23, 2017 at 11:33 | history | edited | CommunityBot | replaced http://stackoverflow.com/ with https://stackoverflow.com/ | |
| Mar 8, 2017 at 6:09 | history | protected | gnat | ||
| Mar 8, 2017 at 5:18 | answer | added | Max Rios | timeline score: 8 | |
| Sep 11, 2016 at 0:19 | answer | added | Martin Sugioarto | timeline score: 5 | |
| Sep 8, 2016 at 21:25 | comment | added | Laiv | You could encode querystring. Lets say Base64 and decode it at server. I have used recently a SOA web service that used this approach and worked fine. RESTful as any other concept in software engineery are not dogmas. Http protocol offers many possibilities. Patterns, architectures and all these stufs may fit well into well known requirements but it does not mean you can not 'customize them'. The dogma here, the rule is your project needs. | |
| Apr 1, 2016 at 19:26 | comment | added | Victor | consider to take a look at: stackoverflow.com/questions/26104394/… | |
| Apr 12, 2014 at 5:48 | vote | accept | Rob Baillie | ||
| Mar 27, 2014 at 14:30 | answer | added | pgraham | timeline score: 6 | |
| Mar 25, 2014 at 8:53 | comment | added | Rob Baillie | I've had a lot of good comments on this and I intend to write an update to the question with the range of answers presented. | |
| Mar 24, 2014 at 7:10 | answer | added | iteratingself | timeline score: 20 | |
| Mar 21, 2014 at 16:01 | comment | added | Cerad | I gave the users the option to name their queries and then retrieve previous query parameters with GET JobSearch/jobSearchId to allow tweaking. All depends on how important the search is to your application. | |
| Mar 21, 2014 at 15:53 | comment | added | Rob Baillie | @Cerad - I like the dedication to the standards! It might be worth us looking at that as an option... | |
| Mar 21, 2014 at 15:46 | comment | added | Cerad | I ended up having POST JobSearch create an actual search entity and returning a jobSearchId. Then GET jobs?jobSearch=jobSearchId returns the actual jobs collection. | |
| Mar 21, 2014 at 15:21 | comment | added | Rob Baillie | That is an awesomely bad idea! I love it! We're implementing it now... | |
| Mar 21, 2014 at 15:17 | comment | added | sea-rob | GET with a body is allowed by the HTTP spec, may or may not be supported by middleware (sometimes not) ;) and isn't favored as a practice. This comes up on Stackexchange periodically. stackoverflow.com/questions/978061/http-get-with-request-body | |
| Mar 21, 2014 at 14:56 | comment | added | Cerad | I did some tests a while back and found that it's possible to include content in a GET request. I'm sure it violates all kinds of stuff but it's one possible way to avoid the GET limits. | |
| Mar 21, 2014 at 14:52 | answer | added | sea-rob | timeline score: 13 | |
| Mar 21, 2014 at 14:51 | history | edited | Rob Baillie | CC BY-SA 3.0 | Updated to reflect reasonable answers |
| Mar 21, 2014 at 14:17 | history | edited | Rob Baillie | CC BY-SA 3.0 | Added more detail to the examples |
| Mar 21, 2014 at 13:58 | history | tweeted | twitter.com/#!/StackProgrammer/status/447009420237869057 | ||
| Mar 21, 2014 at 12:44 | answer | added | p1100i | timeline score: 144 | |
| Mar 21, 2014 at 12:17 | answer | added | Trevor Pilley | timeline score: 8 | |
| Mar 21, 2014 at 11:19 | comment | added | Rob Baillie | I've clarified the question with a more explicit reference to GET limits. In response to your further comment - it's a fair idea and might be worth exploring, but this doesn't solve the problem, it merely defers it to a longer length. | |
| Mar 21, 2014 at 11:18 | history | edited | Rob Baillie | CC BY-SA 3.0 | Added clarification regarding 2000 char limit on GET |
| Mar 21, 2014 at 11:16 | comment | added | Knerd | Actually a very good point. What about specifing a compression technology? | |
| Mar 21, 2014 at 11:13 | comment | added | Rob Baillie | Yes, I can see that for a trivial example there isn't a problem. But in the tool we're building it's actually not that unbelievable that we'd end up with a complex search that results in a GET string longer than 2000 characters. What then? | |
| Mar 21, 2014 at 11:05 | comment | added | Knerd | I often intent to use GET domain/Jobs?keyword={keyword}. This works fine for me :) My hope is, that the SEARCH verb will become a standard. programmers.stackexchange.com/questions/233158/… | |
| Mar 21, 2014 at 10:59 | history | asked | Rob Baillie | CC BY-SA 3.0 |