Wouldn’t be enough to “extend” GET so that it supports a body payload as well?
It already does.
Defining a new HTTP method: HTTP Search (2021)
11–20 of 131 posts
Re: Defining a new HTTP method: HTTP Search (2021)
#12Wouldn’t be enough to “extend” GET so that it supports a body payload as well?
It sort of does, but support is spotty. I've tried using it only to have things like MITM proxies on my customers' corporate networks drop the body. It'd be a large push to get universal support. It may be more difficult than simply adding a new method.
Re: Defining a new HTTP method: HTTP Search (2021)
#13I'm trying to imagine an example of the authors primary use case: "a complicated data retrieval, sending lots of data but not changing the server state". Is he imagine sending something like a SQL statement SELECT with multiple WHERE and JOIN clauses using a recursive CTE?
If defining the attributes of the thing to return takes that much complexity, maybe that's a sign the endpoint is poorly designed, rather than GET query string length being insufficiently large.
Re: Defining a new HTTP method: HTTP Search (2021)
#14being from 2021, I guess this one didnt pan out
Re: Defining a new HTTP method: HTTP Search (2021)
#15This seems reasonable, but unlikely to happen. GET is already pretty much sufficient, especially given that clients generally support megabytes worth of query strings in these modern times. If we're doing this though, I'll cast my vote for naming it more semantically as QUERY, and forgoing whatever little WebDAV compatibility would be had otherwise.
Middle boxes can arbitrarily limit the request URL size in certain cases.
Re: Defining a new HTTP method: HTTP Search (2021)
#16Wouldn’t be enough to “extend” GET so that it supports a body payload as well?
The only software I have seen that does this is Elasticsearch - it works with their client libraries but I'm always worried there may be proxies and suchlike which don't support it.
They support POST as a fallback.
Re: Defining a new HTTP method: HTTP Search (2021)
#17I'm trying to imagine an example of the authors primary use case: "a complicated data retrieval, sending lots of data but not changing the server state". Is he imagine sending something like a SQL statement SELECT with multiple WHERE and JOIN clauses using a recursive CTE? If defining the attributes of the thing to return takes that much complexity, maybe that's a sign the endpoint is poorly designed, rather than GET…
A great example of this today is GraphQL. Even if you disagree with the premise of GQL, you can understand how you can have complicated filtering and sorting logic, and conditional expansion of nested resources. For a nontrivial data model, you may want to select only a minimal number of fields on each nested resource. Having lots of different variants of the same endpoint to serve the same query with different shapes of output is difficult to maintain, so this makes some sense.
Re: Defining a new HTTP method: HTTP Search (2021)
#18Wouldn’t be enough to “extend” GET so that it supports a body payload as well?
It already does.
Sort of, but it’s not that solid: https://datatracker.ietf.org/doc/html/rfc9110#name-get
(paragraph starting “Although request message framing is independent of the method used”)
Re: Defining a new HTTP method: HTTP Search (2021)
#19The advantage of GET is that you can always link to it. Doesn't matter with POST because you're never going to want to link to a POST.
So, GET URLs with base64 encoded data is definitely ugly, but at least you can save them and share them easily.
Re: Defining a new HTTP method: HTTP Search (2021)
#20Or just use GET since it already works. I don't see any problems with large query params. You can also split the search into a POST request and a GET request for the result.
> I don't see any problems with large query params. Most servers will reject URLs after a certain size, 4-8KB.
A query of that size will likely not benefit from a GET anyway so use a POST.