<div dir="ltr">Thanks, Steve. That makes sense, and I tested with a resource with >1000 top level children and I see that only 200 of them are included, which corresponds to the value for "waypoint_size" in the response:<div><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><font face="courier new, monospace">{  <br></font><font face="courier new, monospace">   "child_count":4780,<br></font><font face="courier new, monospace">   "waypoints":24,<br></font><font face="courier new, monospace">   "waypoint_size":200<br></font><font face="courier new, monospace">...</font></blockquote><div><div><br></div><div>So the next question is how do you make the subsequent calls to retrieve the next 200, etc.?</div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jul 23, 2019 at 10:52 AM Majewski, Steven Dennis (sdm7g) <<a href="mailto:sdm7g@virginia.edu">sdm7g@virginia.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;">I believe the rationale of the waypoints was that initially, it was expected that resource children/ archival objects would fall into a more balanced tree structure, but it turned out that there were many flat hierarchies with hundreds of top level children, and getting all of the children at once was not working very efficiently. So with they waypoint calls, you may only be getting some of the children, but the display can start populating the tree display while making additional calls for the rest. <div><br></div><div>I may have some postman examples and internal notes around somewhere: I’ll see what I can dig out. </div><div><br></div><div>— Steve. </div><div><br><div><br><blockquote type="cite"><div>On Jul 23, 2019, at 9:05 AM, Trevor Thornton <<a href="mailto:trthorn2@ncsu.edu" target="_blank">trthorn2@ncsu.edu</a>> wrote:</div><br class="gmail-m_1019186690443663652Apple-interchange-newline"><div><div dir="ltr">Hi everybody-<div><br></div><div>I'm building a service using these API endpoints (or I think I am):</div><div><a href="http://archivesspace.github.io/archivesspace/api/#fetch-tree-information-for-the-top-level-resource-record" target="_blank">[:GET] /repositories/:repo_id/resources/:id/tree/root</a></div><div><a href="http://archivesspace.github.io/archivesspace/api/#fetch-tree-information-for-an-archival-object-record-within-a-tree" target="_blank">[:GET] /repositories/:repo_id/resources/:id/tree/node</a></div><div><br></div><div>These incorporate the concept of "waypoints", which I admit that I'm not familiar with in this context, and it isn't explained very well in the documentation. This is what I have to work with (these are elements included in the API response):</div><div><ul><li>child_count – the number of immediate children</li><li>waypoints – the number of “waypoints” those children are grouped into</li><li>waypoint_size – the number of children in each waypoint</li><li>precomputed_waypoints – a collection of arrays (keyed on child URI) in the same format as returned by the ’/waypoint’ endpoint. Since a fetch for a given node is almost always followed by a fetch of the first waypoint, using the information in this structure can save a backend call.<br></li></ul></div><div>Can anyone explain what exactly waypoints are and how they are different from children? In the examples I've seen, the "precomputed_waypoints" element in the response looks like a convoluted way (an array value of the lone element in an object, which is itself the value of the lone element in another object) to provide the children nodes of the given node (or root). What's the difference?</div><div><br></div><div>Thanks,</div><div>Trevor<br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail-m_1019186690443663652gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><font size="2" style="background-color:rgb(255,255,255)" color="#666666">Trevor Thornton</font><div><font size="2" style="background-color:rgb(255,255,255)" color="#666666">Applications Developer, Digital Library Initiatives</font></div><div><font size="2" style="background-color:rgb(255,255,255)" color="#666666">North Carolina State University Libraries</font></div></div></div></div></div></div></div></div></div>
_______________________________________________<br>Archivesspace_Users_Group mailing list<br><a href="mailto:Archivesspace_Users_Group@lyralists.lyrasis.org" target="_blank">Archivesspace_Users_Group@lyralists.lyrasis.org</a><br><a href="http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group" target="_blank">http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group</a><br></div></blockquote></div><br></div></div>_______________________________________________<br>
Archivesspace_Users_Group mailing list<br>
<a href="mailto:Archivesspace_Users_Group@lyralists.lyrasis.org" target="_blank">Archivesspace_Users_Group@lyralists.lyrasis.org</a><br>
<a href="http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group" rel="noreferrer" target="_blank">http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><font size="2" style="background-color:rgb(255,255,255)" color="#666666">Trevor Thornton</font><div><font size="2" style="background-color:rgb(255,255,255)" color="#666666">Applications Developer, Digital Library Initiatives</font></div><div><font size="2" style="background-color:rgb(255,255,255)" color="#666666">North Carolina State University Libraries</font></div></div></div></div></div></div></div>