I looked at this again and believe I found the issue. If you look at the <linear> node in the response for any of the pages after page 1, you see that it's blank (<linear/>). It looks like the logic is implemented in such a way that it's paging through both the threads and the replies to those threads (which show up in the <linear> node). So when you specify page=2, it is returning you the second page of results for threads but is also returning you the second page of results for the replies that go in the linear tag -- for many threads, there is not a second page of replies and so the <linear> tag shows up as blank.
To test this out, create a new thread in the community, then do a threads/recent call with page=2&page_size=1 -- you'll see a blank <linear> tag in the results. Now post a reply to that thread and do the threads/recent call again with page=2&page_size=1. Assuming no one else has posted a new thread in the meantime, you should get the same thread back, this time with the reply you gave in the <linear> tag.
This is strange behavior to say the least and there is a bug filed for it.
You should be able to work around this problem by using either the topics/recent call then doing a /threads/id/<thread id>/messages/linear call for each thread returned in the results (you could combine the 2 calls in an endpoint if needed).
-Doug
We have 1400+ threads and it keeps on increasing.... It will take 1 call for first 1000 threads and another 400+ calls for other threads. It keeps timing out and causes issues. Please fix the issue and let me know. Thanks once again.
We have a new version of our REST API coming out very soon, which will include a query language that will allow you to retrieve this information in a single call. In the meantime, you could create an Endpoint in Lithium Studio that combines these calls (so you only have to call one endpoint over HTTP).
