We need to fetch a configurable amount of posts via API

[taz.de]

I had a discussion with IPS Support which ended with that they asked me to post this here:

------------------------------
We are using IPB over the API
Yet, we still have IPB3 in production use and are able to fetch all posts for a certain topic or user at once,
In our development/testversion we use to update our code to IPB4 suddenly it was only possible to fetch as many posts as configured in adminCP for "posts per page".
Now, since the latest updates, the count of posts we could fetch over API is hardcoded in system/Api/PaginatedResponse.php to a maximun of 25 posts.
We can't really work with that. Could you PLEASE change that, so that we can fetch a free count of posts and/or all posts per user/topic or at least make that free configurable through the adminCP?
------------------------------

The discussion was much longer ad i am a bit angry that such "design decisions" are being made on the back of the API-users. We need a flexible API, thats why we are using the API. I mentioned the perormance overhead we'll produce if we fetch pages with 25 posts on each and IPS anserwed "Whilst I appreciate the performance overhead you are referring to here, this would be nothing in comparison to someone calling 1 million posts in a single hit, which could simply grind a server to a halt straight away." Oh, okay - and thats the reason to limit the posts to 25??? I mean, twenty-two!!! i completely don't understand the logic behind this idea. if the user wants to grind his server, let him! let him decide how secure he wants to be, let him decide which count of posts he would like, let him decide if he wants pagination and in with page-length. if a user uses the API, he knows what he is  doing. i hope

[bfarber]

We are always interested in improving the REST API and I expect you will see changes in this area in an upcoming release.

[IPBWI.com Matthias Reuter]

hope we will see here some improvement soon, as for large queries, we have a massive performance bottleneck using the API due to required query iteration. Hardcoded limits are so 2017...

[bfarber]

I am fairly confident you will see the ability to specify the number of results per page introduced in our next big release.

 

[taz.de]

thank you very much! even if i had to solve this at my own now, i would be glad to be able to get that with less performance usage. there are some other little issues, eg. i don't understand why we are not able now anymore to change the users birthday via the api. i am afraid i have to realize that by accessing the database directly, or with copying any birthdays from the basic member fields to the custom profile fields ... could you tell me if there is a chance that this will also be possible via api in the future?

[bfarber]

More information about the REST API changes expected in 4.3 will be forthcoming in our news area before long.

 

[taz.de]

thanks, for now i only found the sentence "REST API has many enhancements to mange members." and no detailed info about the changes of the API. but that doesn't sound bad.