Should /web and /search support GET requests?

[dhimmel]

We were curious regarding the reason to have the /web and /search endpoints encode the query as POST data rather than GET URL Parameters? The benefits of GET would be:

1. Easier querying for casual users. For example, queries could be single URLs that would work in a browser as opposed to requiring curl.
2. Easier caching via a reverse proxy. We are running tranlsation-server behind nginx and would like to cache repetitive queries, but caching responses based on POST data appears to be non-standard.

Would it be possible to support both POST data and GET URL parameters? Alternatively, is there a built-in caching solution to deal with 2?

[dhimmel]

@dstillman any thoughts on this?

Manubot now has a frontend developer on our team (@vincerubinetti), so it's possible we could contribute some develop efforts towards this issue.

[mvolz]

You could try using citoid which does this and then queries translation-server, but running two services might be overkill for your use case :). https://www.mediawiki.org/wiki/Citoid/API