ubuntu-phone team mailing list archive

[Natalia <natalia.bidart@xxxxxxxxxxxxx>]

On Thu, Mar 6, 2014 at 4:54 AM, Michael Nelson
<michael.nelson@xxxxxxxxxxxxx> wrote:
> On Wed, Mar 5, 2014 at 7:45 PM, James Tait <james.tait@xxxxxxxxxxxxx> 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.