Hi Adam, thank you for the answer! But what do you think about separating this endpoint to 2 different endpoints which will be working for pages and list ? I think it will be clear and easy to refactor for architecture with using DTO, and of course it'll be a single responsibility.
On Mon, Mar 10, 2025 at 1:25 AM Ádám Sághy <adamsa...@gmail.com> wrote: > Hi Viktor, > > Thank you for getting interested in how we can make Fineract better! > > I think you have a valid point here, having an audit endpoints which was > returning List of items, unless “paged” query param was provided, then it > was returning paginated list of items is hard to maintain. > > I think you did the 1st step to resolve this situation by raising > awareness about this. > > I agree with your proposal to mark one of this behaviour as deprecated: > From practical point of view I also agree with you and we should keep only > the version where the results are retrieved as pagination result set. > > *However, I feel I need to raise awareness the default behaviour is not > the paginated result set, so we are talking about breaking change here!* > > Kindly asking the community to chime in to this conversation and share > their thoughts! > > Regards, > Adam > > On 2025. Mar 6., at 10:32, Viktor Pavlenko > <viktor.pavle...@onix-systems.com.INVALID> wrote: > > We have some, i think, deprecated response in Audits API in GET /v1/audits > endpoint and our response depends on the query param like "paged".. When we > have "paged" is true we'll have a pageable response but if "paged" false > it'll be List<>. Therefore, it's impossible to refactor a normal struct > with use dto.. Probably, one of the type is deprecated yet and needs to > only use Page<> response, and we can easier remove List<>? > > >
