3 ms·

If you need to have lots of query parameters (I'm assuming that's what you're referring to) then something is wrong in your design. Start by dividing your probl

If you need to have lots of query parameters (I'm assuming that's what you're referring to) then something is wrong in your design. Start by dividing your problem into simpler parts and go from there. A dumb idea would be to encapsulate various options into a single query parameter. Compressing query parameter's names and values and encoding them in base64 (or some other base of your choice) might also help. But all of this will just add tons of needless complexity to it. Do you really NEED 20+ query parameters? I am curious, though. What are you actually trying to achieve here?

larryfreeman 7y ago
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.

larryfreeman 7y ago

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.