1

I would like to pass a list of objects to a java rest service. For example, list of cycles.

class Cycle { private String id; private LocalDate date; } @GetMapping("results") public Result results(List<Cycle> cycles)

Or have a CyclesWrapper class that contains the list. Instead of passing a List cycleDates and a List cycleIds.

How would I pass the parameters to the rest service using say POSTMAN or curl?

So, for passing in a List<String> says cycleIds, the request would be: http://localhost:8080/application/results?cycleIds=xx,yy

For passing in a Cycle says cycle, the request would be: http://localhost:8080/application/results?date=2020-10-17&id=xx

Thanks

Improve this question
1
  • What are you trying to do? You can usually send things as query parameters, in the body or as headers. Spring allows you to bind all of these to method parameters. However, as answered here: stackoverflow.com/a/983458, you can't send a body with a GET request and it doesn't make much sense to send JSON in either headers or query parameters (and I don't know if Spring can then deserialize it into objects). Commented Nov 2, 2020 at 15:20

1 Answer 1

Reset to default
3

As it currently stands, your endpoint would interpret cycles as a query parameter, meaning that it would expect the following kind of request:

GET /results?cycles=...

With a list of complex objects, this is not the standard approach. You could possibly pass the objects as /results?cycle1Id=abc&cycle1Date=22-10&cycle2Id=def&cycle2Date=10-10&..., but this would be extremely cumbersome, error-prone, and would require custom mapping on your end to make it work. Additionally, as far as I am aware, there is no standard for sending query array parameters.

Note also, in case you might have misconstrued: you cannot send a request body on a GET request - while the standard does not explicitly disallow this, almost every server's handling of GET does not accept (or just flatly ignores) a request body.

Instead, what you could do, is either:

  1. Change the endpoint to a POST endpoint, passing the list of cycles (i.e. filters) as standard @RequestBody JSON. This would look as follows:
@PostMapping("results") public Result results(@RequestBody List<Cycle> cycles)

Now your request would expect:

POST /results { [ {"abc", "22-10"}, {"def", "10-10"} ] }

Since POST is allowed to pretty much do anything, it could also return a filtered response on this endpoint. This would however, not be very RESTful.

  1. Change your GET to accept two lists of of simple (i.e. non-nested) objects, e.g. String and LocalDate.
@GetMapping("results") public Result results(@RequestParam List<String> ids, @RequestParam List<LocalDate> dates)

Which would then expect a request as follows:

GET /results?ids=abc,def&dates=22-10,10-10

as a comma-separated list. This is more in tune with RESTful endpoints, although it's also kind of cumbersome.

In the end, it seems like your endpoint is trying to do two things at once: filter on id and date. Since I am not sure what kind of logical work represents a cycle, perhaps these should be split up into two different endpoints, e.g.:

===> GET /results?dateFrom=22-10&dateUntil=23-10 <=== [abc, def] ==> GET /results/abc?dateFrom=22-10&dateUntil=23-10 <== abc detailed view

Where the /abc represents a singular object. Whether this represents a result or a cycle in your specific case, I cannot say. You'd have to evaluate that for yourself.

Improve this answer
Sign up to request clarification or add additional context in comments.

3 Comments

Thanks for your response. I would like to stick to a GET request and avoid a json body. i will probably split into two lists (id, dates).
One thing to note: you could replace the @RequestParam annotations with @QueryParam if you wish to explicitly only allow them as query parameters. @RequestParam is a bit more lax, and allows these fields to be present elsewhere in the request (e.g. as form data). If you do this, you should also add @QueryParam(required=true), as query parameters may be null by default.
Are there still issues you're facing? If not and this has helped you, please consider accepting the answer. :)

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.