POST-as-GET isnt defined in the spec

There are legitimate scenarios where POST-as-GET makes more sense than a simple GET request. Such as having to query a large amount of data where using many query params is not an appropriate option.
Unfortunately this scenario isn’t defined in the spec. It would be a good idea to define this in the spec before we see inconsistent approaches in the wild.

What would be the appropriate POST body for this scenario?
Proposed #1
“data”: {
“attributes”: {
“purls”: [



Pros: consistent with other APIs (update/create)

Proposed #2

Pros: removes extra envelope (attributes) so improves UX

Could you elaborate more on the problem you are trying to solve? The amount of data queried should not have any impact on the request. The amount of query parameters seems to be only related to complexity of sorting, filtering and inclusion rules defined in the request. Are you running into URL length limits with your use case?

yes there is a url length limit so that constraint alone shows that sending a large payload in the url isnt a good solution. Having it in the body as a post request solves the issue but its not defined in the spec.

HTTP specification does not have a limit for request URI as far as I know. The limit depends on implementation. If I recall correctly, nginx and apache both have a limit of 8 kb as default. Both allow to increase it in configuration.

Do you deal with a stack having a much lower limit, which can not be changed? Or do you have such complex filtering rules exceeding 8kb?

I think most clients will have a url char limit and its bad UX to send a get request with100+ query params. Are you aware of any popular APIS that allow get requests with large query params? I think a POST as a GET is more UX friendly.