POST-as-GET isnt defined in the spec

1

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”: [
“purl”

    ]
}}

}

Pros: consistent with other APIs (update/create)

Proposed #2
{“data”:[“purl”,“purl”,…]}

Pros: removes extra envelope (attributes) so improves UX

2

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?

3

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.

4

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?

5

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.

6

APIs supporting requests with 100+ query parameters seem an edge case to me. I can not recall that I have any come around such API. Neither in my professional work nor in my open-source activities. I don’t think such edge cases need to be addressed by the base specification.

I haven’t deeply looked into the topic but I assume, what you are proposing is possible using an JSON:API extension. Unless that assumption is wrong, such use cases can be well addressed.

I’m not aware of many HTTP APIs, which uses POST and a request payload for fetching data beside GraphQL. Especially not REST APIs as it also goes against core concepts of the REST API pattern.