JHoward
JHoward

Reputation: 31

Which HTTP Verb for Read endpoint with request body

We are exposing an endpoint that will return a large data set. There is a background process which runs once per hour and generates the data. The data will be different after each run.

The requester can ask for either the full set of data or a subset. The sub set is determined via a set of parameters but the parameters are too long to fit into a uri which has a max length of 2,083 characters. https://www.google.co.uk/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=uri%20max%20length

The parameters can easily be sent in the request body but which which is the correct HTTP verb to use?

GET would be ideal but use of a body 'has no semantic meaning to a GET request' HTTP GET with request body

PUT is not appropriate because there is no ID and no data is being updated or replaced.

POST is not appropriate because a new resource is not being replaced and more importantly the server is not generating and Id. http://www.restapitutorial.com/lessons/httpmethods.html

GET (read) would seem to be the most appropriate but how can we include the complex set of parameters to determine the response?

Many thanks

John

Upvotes: 3

Views: 2250

Answers (3)

Pedro Werneck
Pedro Werneck

Reputation: 41898

POST is the correct method. POST should be used for any operation that's not standardized by HTTP, which is your case, since there's no standard for a GET operation with a body. The reference you linked is just directly mapping HTTP methods to CRUD, which is a REST anti-pattern.

Upvotes: 2

Szabolcs Heilig
Szabolcs Heilig

Reputation: 119

Assuming that the queries against that big dataset are not totally random, you should consider adding stored queries to your API. This way clients can add, remove, update queries (through request body) using POST DELETE PUT. Maybe you can call them "reports".

This way the GET requests need only a reference as query parameter to these queries/reports, you don't have to send all the details with every requests.

But only if not all the requests from clients are unique.

Upvotes: -1

Julian Reschke
Julian Reschke

Reputation: 42017

You are right that GET with body is to be avoided. You can experiment with other safe methods that take a request body (such as REPORT or SEARCH), or you can indeed use POST. I see no reason why the latter is wrong; what you're citing is just an opinion, not the spec.

Upvotes: 1

Related Questions