Reputation: 18861
We're building a simple API to get Bars that belong to a given Foo using pagination like like:
GET /foo/1/bar?pageSize=50&pageOffset=1
On the backend, we utilise Spring Data JPA pagination support like:
Page<Bar> barsPage = repo.findBarsForFoo(fooId, new PageRequest(pageOffset, pageSize));
We need to filter out certain elements from barPage - easy, like:
List<Bar> filtered = barsFilter.removeSome(barsPage.getContent())
Filtering component delegates to other services (let's call them rejectors):
class BarsFilter {
@Autowired Rejector1 rejector1;
@Autowired Rejector2 rejector2;
public List<Bar> filterSome(List<Bar> bars) {
return bars.stream()
.filter(bar -> rejector1.matches(bar))
.filter(bar -> rejector2.matches(bar))
.collect(toList());
}
}
The problem is that API client will get smaller amout of items than they requested.
Filtering logic is complex and it relies on other components. It can't be written as a single DB query.
What would be the most reasonable thing to do here? Return a smaller page? Artificially increase the page size? Utilise some Spring Data or JPA mechanism to support this custom logic?
Upvotes: 4
Views: 1023
Reputation: 3593
In my opinion it release depends what you will send by this API.
Case 1: You want to obtain notification list -> than you can just simply return smaller list, after removal of some of them, and it will not affect the UX.
Case 2: You want to obtain ranking of 20 users for specific country, that's why you remove some of them. Then you really need to return 20 users, so it's better to implement some customised logic. Artificially increased page sounds not efficient at all.
Hope that helps.
Upvotes: 1