-2

I am developing a REST api endpoint that accepts a list of item IDs and will return some details for each item.

Let's make the following assumptions

  • Performance wise in the DB there is no significant difference whether the endpoint accepts 10/100/1000 etc IDs.
  • The details that will be returned for each ID are a JSON with no more than 10 key-values or so per ID. No nested items that can bloat the response payload.
  • This is a GET request. So the IDs will have to be sent to the endpoint in the query of the request

The question then is how to determine the maximum number of IDs a single request should handle?

If there is no business reason should I limit the maximum number (maybe to make the request more human readable and the logs easier to work with) or let the technical limitations (such as maximum url length) be the only limits.

Improve this question
6
  • Please suggest ways to improve the question along with the downvotes :) Commented Jul 27, 2020 at 9:52
  • 1
    Do you have a business reason to limit it? Commented Jul 27, 2020 at 9:54
  • 1
    Since you're talking about a GET request, this might interest you. BTW, your question is being downvoted because it lacks a reason why you would want to limit it. Generally, "best practice" questions are not good questions, since they lead to opinionated answers. Commented Jul 27, 2020 at 9:58
  • @Andy this will be deployed as a aws Lamba behind an API Gateway. And the limit for that according to documentation is Length, in characters, of the URL for a regional API : 10240. But thanks for the input Commented Jul 27, 2020 at 10:00
  • @Caleth There is no business reason to limit it at the moment. Commented Jul 27, 2020 at 10:03

1 Answer 1

Reset to default
1

Its really useful to be able to request all the things. But there are technical limitations the number you can send, even if its just the network bandwidth.

This is super annoying because it means you have to have some way to indicate to the client that you haven't been able to send all the things they want in one go and they need to request page 2

Plus it means the client has to write code to check for this signal and to request more pages if required.

A common way to do this is to wrap the returned collection in some other meta object which indicates the number returned, the total number and what page this is. But this adds a whole layer of what is basically a transfer protocol to HTTP

In your scenario, where you can presumably return all the results you want most of the time, it might be better to having optional pagination parameters, limit and page, and simply error if there are say over 10mb worth of results.

The client can then work unconcerned with limits in normal use and use the limit and page parameters when requesting lots of data.

Improve this answer
1
  • We opted for mandatory pagination but a high limit on page size. So most of our clients can get what they want with one request. Thanks for your feedback. If we were to return an error if the response becomes too big what would be an appropriate code? I don't think 5xx is right as there is no error in the server side. Is 409 or 416 a good choice? Commented Jul 29, 2020 at 8:02

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.