On Thu, Mar 6, 2014 at 4:54 AM, Michael Nelson <michael.nel...@canonical.com> wrote: > On Wed, Mar 5, 2014 at 7:45 PM, James Tait <james.t...@canonical.com> wrote: >> I've had a couple of thoughts about how we might approach this: >> >> - Pass them as discrete GET parameters. This has the benefit of being >> easy to test in a browser, and totally transparent. It's also less >> likely to be problematic with caches. On the down side, it will >> lead to very large URLs. >> - Pass them as request headers. This keeps the URL shorter and more >> focused and is better aligned with other non-user-query attributes >> such as GeoIP information and language settings, at the expense of >> being largely invisible, (more) difficult to test in the browser, >> and may break caching. > > +1 for this second option. If the default behaviour when the headers > were missing was to present all results (is that what you meant by > them not being strict requirements?), then testing in the browser > won't be any more difficult for some queries, and curl is easy enough > to test with the headers for anyone (if we have a page with examples > for testing).
+1 too I need to reuse the architecture and framework filtering for the highlights endpoint, and I was also wanting to separated these from the "q" param for search. -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
