CODEWITHSUNDEEP
javaspring-bootrestspring-restcontroller
christopher.online
christopher.online

Reputation: 2774

REST endpoint request/filter by ids

Requirements:

My first idea was to use a GET endpoint like this in my RestController:

@GetMapping(path = "{ids}")
public List<FooResponseTO> getFoos(@PathVariable @NotEmpty Set<UUID> ids) {
    return someService.getFoos(ids);
}

This idea does not seem to be optimal because URL length is limited (for example in browsers). I think it would be best to move the ids to the request body but that is not recommended for GET requests. Using POST instead of GET seems also wrong since GET is supposed to be used to request data from a specified resource and POST is supposed to be used to send data to create or update a resource.

What is the best way to design the endpoint to meet the requirements?

Upvotes: 1

Views: 1045

Answers (1)

VoiceOfUnreason
VoiceOfUnreason

Reputation: 57257

What is the best way to design the endpoint to meet the requirements?

There isn't a "best" way to do this, today. Just a bunch of different compromises.

In late 2020, the HTTP working group agreed to adopt SEARCH - that method's semantics are going to be extended to cover some "GET with a body" cases; when it has been standardized and vendors start supporting it, that will be your best choice.

In the mean time, your standardized options are GET (with the arbitrary list of URI encoded in the URI, and the liabilities that come from exceeding URI length limits), and POST (losing the advantages of safe semantics, and compromising caching).

Another possibility would be to switch your resource model from fine grained (ask for exactly the identifiers you want) to coarse grained (get pages of identifiers, let the client get the ones that they want). Coarse grained resources are a much better "fit" for large scale applications, because caching.

If you aren't limited to standardized choices (for example, because you control both the client and the server) then you could also consider using an unstandardized SEARCH method-token, or inventing your own method-token to mean precisely what you need it to.

Upvotes: 3

Related Questions