Hi All, If I run: https://eti.spiraservice.net/Services/v6_0/RestService.svc/projects/43/artifact-types/6/artifacts/27000/history?start_row=1& number_rows=20 &sort_property=HistoryChangeId&sort_direction=desc Spira returns 8 history items. So, we know that in reality there are 8 such history records. But If I run: https://eti.spiraservice.net/Services/v6_0/RestService.svc/projects/43/artifact-types/6/artifacts/27000/history? start_row=21 &number_rows=20&sort_property=HistoryChangeId&sort_direction=desc It returns again 8 records. Expected behaviour to return nothing as start_row is out of available array of records. Why does it matters? Lets imagine that my goal is to receive all the history. So, I dont know number of rows what to set for number_rows attribute. Lets Imagine that I am using windowing of 8 records per request. So, sending: https://eti.spiraservice.net/Services/v6_0/RestService.svc/projects/43/artifact-types/6/artifacts/27000/history? start_row=1 &number_rows=8&sort_property=HistoryChangeId&sort_direction=desc I will receive 8 records. But I dont know are there any other records, so will send again: https://eti.spiraservice.net/Services/v6_0/RestService.svc/projects/43/artifact-types/6/artifacts/27000/history? start_row=9 &number_rows=8&sort_property=HistoryChangeId&sort_direction=desc But will receive again 8 records so I wont get a signal that there are no more records in a history and will request Spira again and again. As a manager, I dont like messages without proposals, so will try to do the same here. Possible ways to solve it: Add another POST API to receive amount of records that might be returned if I call original one request later. Change the logic of the original one API to send nothing as soon as I get to the end and after the end. Add attribute &stop=true to the original one API to apply such logic only for those clients, when it is needed. Proposals doesnt contradict each other, so 1 and 3 (or 2) could be implemented in parallel to fix it. en-US(C) Copyright 2006-2026 Inflectra Corporation.support@inflectra.com/Computers/Software/Project_Management//Computers/Software/Quality_Assurance/KronoDesksupport@inflectra.comhttp://www.inflectra.com/kronodesk/forums/threads120/Support/Forum/spirateam/issues-questions/2578.aspxthreadId=2578Ilia Poliakov (ilya.polyakov@edetek.com)restapi post start_row number_rows Hi All, If I run: https://eti.spiraservice.net/Services/v6_0/RestService.svc/projects/43/artifact-types/6/artifacts/27000/history?start_row=1& number_rows=20 &sort_property=HistoryChangeId&sort_direction=desc Spira returns 8 history items. So, we know that in reality there are 8 such history records. But If I run: https://eti.spiraservice.net/Services/v6_0/RestService.svc/projects/43/artifact-types/6/artifacts/27000/history? start_row=21 &number_rows=20&sort_property=HistoryChangeId&sort_direction=desc It returns again 8 records. Expected behaviour to return nothing as start_row is out of available array of records. Why does it matters? Lets imagine that my goal is to receive all the history. So, I dont know number of rows what to set for number_rows attribute. Lets Imagine that I am using windowing of 8 records per request. So, sending: https://eti.spiraservice.net/Services/v6_0/RestService.svc/projects/43/artifact-types/6/artifacts/27000/history? start_row=1 &number_rows=8&sort_property=HistoryChangeId&sort_direction=desc I will receive 8 records. But I dont know are there any other records, so will send again: https://eti.spiraservice.net/Services/v6_0/RestService.svc/projects/43/artifact-types/6/artifacts/27000/history? start_row=9 &number_rows=8&sort_property=HistoryChangeId&sort_direction=desc But will receive again 8 records so I wont get a signal that there are no more records in a history and will request Spira again and again. As a manager, I dont like messages without proposals, so will try to do the same here. Possible ways to solve it: Add another POST API to receive amount of records that might be returned if I call original one request later. Change the logic of the original one API to send nothing as soon as I get to the end and after the end. Add attribute &stop=true to the original one API to apply such logic only for those clients, when it is needed. Proposals doesnt contradict each other, so 1 and 3 (or 2) could be implemented in parallel to fix it. Tue, 22 Feb 2022 05:13:58 -05002022-02-22T11:11:06-05:00/Support/Forum/spirateam/issues-questions/2578.aspxmessageId=4276David J (adam.sandman+support@inflectra.com) Please could you log a support ticket so your request can be added to our backlog. Regards David Tue, 22 Feb 2022 11:11:06 -05002022-02-22T11:11:06-05:00/Support/Forum/spirateam/issues-questions/2578.aspx#reply4276