3

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

Community
  • 1
  • 1
JHoward
  • 31
  • 3

3 Answers3

2

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.

Pedro Werneck
  • 40,902
  • 7
  • 64
  • 85
1

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.

Julian Reschke
  • 40,156
  • 8
  • 95
  • 98
  • Thanks for your comments Julian. https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html At the riskk of starting a conversation the I anm sure neither of us has time for... 9.5 - there is no subordination so POST would seem out. 9.6 - the enclosed entry will not be stored so PUT would also seem inappropriate. I really like the concept of REPORT so will investigate this further - many thanks for the pointer! – JHoward Dec 07 '16 at 17:29
  • RFC 2616 is entirely irrelevant. See https://greenbytes.de/tech/webdav/rfc7231.html#POST for the current specification. – Julian Reschke Dec 07 '16 at 18:41
-1

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.

Szabolcs Heilig
  • 109
  • 1
  • 4
  • Hi Szabolcs, the solution actually does store some queries and we cater for exactly the scenario you have suggested (great minds!) but in this context, the request is for a sub set of data and the requestor is not allowed to store their request. Maybe we should reconsider this though. Thanks for the idea. – JHoward Dec 07 '16 at 17:36