Alternative way so specify the search parameters?

[archiloque]

When using the API, the current document search syntax is working but is a bit awkward.

I'm thinking that a more HTTP-y syntax would be easier to use, and it would avoid to add even more code to the parser in charge of extracting the search parameters when a new parameter is added.

A possible approach would be to be able to pass the search parameters as HTTP params. As far as I see there would be no conflict with the existing parameters. To be more future proof a prefix could be added (like search_uafter).

What do you think of it?

I could add the feature to the API and add a new method to the Android lib, but probably not migrate the frontend.

[jendib]

It makes sense, however the frontend should keep the current user friendly way of searching (I took this from Gmail), so the frontend code will need to generate those query params itself.

[archiloque]

Yes it what I meant, as the frontend provide the params as a field list it feels like it should be doable without too much hassle.

What's your opinion on how to send the params (HTTP params with plain name, use a prefix, something else)?

[jendib]

• search[uafter]
• search_uafter

something like this (I already saw both in other apps. It should be able to handle lists as well (like multiple tags).

[archiloque]

Thanks, it's nice to have a plan, I think I'll maybe try something but I'll have a real look at it when my other PR will be dealt with, to avoid any risk of merge conflicts.

[archiloque]

As I'm looking at the search code I have troubles understanding what is supposed to happen when a parameter is invalid, for example when a user does not exist: is the search supposed to return nothing at all, or maybe only suggestion ?

[archiloque]

Also another question: it seems the tools used to generate the API pages don't like ! in parameter name and don't display them, do you have a suggestion to replace !tag?