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<>?
>
>
>

Reply via email to