REST, multiple paramters in the URL will reach URL char limit at some point

Question

I have the following two API-methods:

1)

@GetMapping("search/findByProjectIds")
public ResponseEntity<List<DailyEntry>> getDailyEntriesFromProjectIds(@RequestParam long[] id) {
  return dailyEntryService.getDailyEntriesFromProjectIds(id);;
}

An API-request looks like:

http://localhost:8080/api/dailyEntries/search/findByProjectIds?id=1001&id=1002&id=1003&id=1004

2)

@PatchMapping("/{id}")
public ResponseEntity<?> partialProjectUpdate(@PathVariable List<Long> id, @RequestBody EntryStatus status) throws DailyEntryNotFoundException {
  return dailyEntryService.partialDailyEntryUpdate(id, status);
}

An API-request looks like:

http://localhost:8080/api/dailyEntries/1758,1759,1760,1761

That was the recommended way i found of sending multiple IDs for a GET/PATCH request.

Problem: In some cases i have a lot of IDs i want to send. With more data in the future, i might reach the URL character limit at one point. To avoid that, i could be sending the IDs in the Body instead of the URL. The problem is that a) GET doesnt have a body, i would need to use POST for it b) that would break our and the recommended REST-API design.

Is there a better solution?

URIs themselves do not have a character limit. Such a character limit may be introduced by browsers or HTTP frameworks. HTTP is furthermore not ideal for batch-processing tasks, such as updating multiple resources with one request simply as the URI, which is the de-facto cache-key, can't be used to evict payload of affected entries. I.e. you might have retrieved (and therefore cached) item 1758 before and now want to update 1758-1761 in one go, how should the cache know that it needs to invalidate any cached data for 1758 now? It can't and shouldn't deduce knowledge from the URI directly — Roman Vottner, Nov 19 '19 at 15:02

score 0 · Answer 1 · edited Oct 07 '21 at 13:21

Is there a better solution?

Not today, no.

GET gives you a couple important elements. One is that it is safe (by definition), another is that general purpose components all share the same understanding of the caching rules.

The only method in the HTTP registry that is close to that is SEARCH, but SEARCH is badly entangled with WebDAV, and isn't generally useful.

A possibility, which may or may not fit your needs, is to think in terms of a URI shortener; you find a resource by POSTING information, and you get redirected to a resource with a simpler identifier that means the same thing. (In effect, the server has a key value store: the key is the identifier, the value is all the junk that you had to put into the POST body).

It's analogous to creating a resource, and then using the identifier for the created resource from that point on. Which restores you to a situation with safe semantics and standard caching, but it isn't as straightforward as the case where all of the interesting things can just be encoded into the URI itself.

score 0 · Answer 2 · answered Nov 19 '19 at 16:07

0

GET has querystring length limitation (Refer What is the maximum possible length of a query string?). If you anticipate more id, then better switch it to POST

answered Nov 19 '19 at 16:07

sam

1,937
1
8
14

REST, multiple paramters in the URL will reach URL char limit at some point

2 Answers2