Search query: GET or POST and why (or when)?

How is this even a question?

GET <- retrieve information
POST -> send information

Unless.... but it's highly unlikely using REST, you need to send data to the server that's not sustainable or practical using query params.

Think SOAP / xml based.

The Biggest search engines use GET.

There are some privacy respecting search engines which allow you to use POST for searching, this Allows you to not having your search terms in your browsing history.

@C0D4 it wasn't really posed as a question. Someone replied to my PR with: 'using a GET for a search query seems odd to me'.

Imo there are valid reasons to use a POST in some circumstances...

But with POST you lose caching (without extra headers), bookmarkability, good browser back button behaviour and you have to go through the headache of maintaining compatible body models if you're strongly typed

@PeterDCarter Posting a search query doesn't seem right.

Your communicating with an endpoint, a get is asking for data.

You wouldn't ask for data in a post unless the server wasn't following rest best practices.

a post is typically sending it data to deal with, you may get a response.

I can understand using a post if you need to send xml or similar but for rest it's more of an anti-pattern.

@C0D4 I agree in principle, but what if you hit the query limit or want to search based on a complex object or several? Create a bespoke query string format?

@PeterDCarter ?

Given you can send 1000's of characters at most servers these days, are you really using rest endpoints if your using what I could assume is database queries with that kind of limit hitting?

sounds like graphql would be a better fit not rest for what your doing.

@C0D4 possibly would be better for what might otherwise be POST scenarios... I've used OData but not GraphQL, and that's very powerful but sometimes does use POST for complex queries. Does GraphQL always use query string? I can consider a situation where a query can exceed 1000 chars...

It's not what I'm doing atm: the person posted as a response to a simple endpoint with a query string and a max matches parameter, which is tied to an external service that's unlikely to change much. I just like to seek additional opinions (where practicable) before calling someone out on something if there may be additional angles I didn't consider.

@C0D4 Startpage does use POST for search requests not originating from browser's search bar for privacy reasons, so the search term is not logged in the browser's history.

In addition to the general rule of using POST for alteration and GET for retrieval, you also need to use POST when doing retrieval protected by a CSRF (cross site request forgery) prevention Token.

Normally you wouldn't protect data retrieval that way. But if log read access, you definitely should.

@realngnx "The GET request means retrieve whatever data (in the form of an entity) is identified by the Request-URI" -- Source: W3C RFC 2616

Yes you can do it but it still kinda violates the spec (depending on if you read the above as exclusive) and it might not work with your libraries etc and/or cause problems with other integrations down the line...

@realngnx it says the retrieved data is identified by the URI. Implication is by that exclusively. Why would you include a body in a GET if not to help identify what data you want? And if the job of the URI is to identify the data, what's the body doing?

All things may be permitted, but if you invoke W3C are you not judged by the invocation?

GET obviously, it will also log in browsing history which is expected behaviour.

if it's not in the spec, it's an anti pattern to the spec, so long as you follow the spec that is.

Or to put it another way:

A GET with a body is like a dildo with a condom.

It's not expected, but I'm sure someone feels better for it.