4 ms·

The purpose of the service is data retrieval based on up to 2,000 ids where the data retrieved can then be aggregated as a csv file. The current service does o

The purpose of the service is data retrieval based on up to 2,000 ids where the data retrieved can then be aggregated as a csv file. The current service does one id at a time which prevents optimizing the retrieval. Allowing 20+ ids enables 20+ data items to be extracted in a single database retrieval call instead of 20+ separate ones which is currently being done. So, from my view, the question is whether it is better to use a GET with a request body or use something such as a POST even though the request is read only.

AnotherIdiot 7y ago
Hrmm, I see. Using GET with a request body is undefined behavior as per RFC. What this means is that there's a very high likelihood of things breaking in the future, because each software vendor as their implementation. You'd probably need to test the software you are using internally. Can't you use a range for said ids? Like GET /blah?from_id=0&to_id=2000 Or are these said ids distinct from each other, like GET /blah?id1=v&id2=v&idN=v ... until id2000? If the latter is what you're dealing with then this looks like bad design, IMHO. You might need to redesign this if possible, otherwise you'll be building on a house of cards. It's just a matter of time.
- larryfreeman 7y ago
  Each id is distinct so there is no way to list them other than to actually list each id. Typically, this will be 200 ids that are alphanumeric and where a range would include the wrong ones. Based on the discussion here (thanks to everyone!), we have decided to use a POST instead of GET. :-) The reasoning is that while GET works fine now, there is always a chance that it will not work in the future either because of security decisions by DevOps or because of use of a third-party tool that does not support GET with request body.

4 ms·

The purpose of the service is data retrieval based on up to 2,000 ids where the data retrieved can then be aggregated as a csv file. The current service does o

by larryfreeman 7y ago

AnotherIdiot 7y ago
Hrmm, I see. Using GET with a request body is undefined behavior as per RFC. What this means is that there's a very high likelihood of things breaking in the future, because each software vendor as their implementation. You'd probably need to test the software you are using internally. Can't you use a range for said ids? Like GET /blah?from_id=0&to_id=2000 Or are these said ids distinct from each other, like GET /blah?id1=v&id2=v&idN=v ... until id2000? If the latter is what you're dealing with then this looks like bad design, IMHO. You might need to redesign this if possible, otherwise you'll be building on a house of cards. It's just a matter of time.
- larryfreeman 7y ago
  Each id is distinct so there is no way to list them other than to actually list each id. Typically, this will be 200 ids that are alphanumeric and where a range would include the wrong ones. Based on the discussion here (thanks to everyone!), we have decided to use a POST instead of GET. :-) The reasoning is that while GET works fine now, there is always a chance that it will not work in the future either because of security decisions by DevOps or because of use of a third-party tool that does not support GET with request body.