我们需要为startDate小于今天日期且endDate大于今天日期的用户查找所有课程。我们正在使用API
/d2l/api/lp/{ver}/enrollments/myenrollments/?orgUnitTypeId=3
在一个特定的案例中，我有超过18000个针对一个用户的课程。该服务不能一次返回18000条记录，我一次只能获得100条记录，所以我需要使用书签字段来获取100条记录中的数据。Bookmark是我们获取的最后100条记录的courseId，以获得下一组100条记录。
/d2l/api/lp/{ver}/enrollments/myenrollments/?orgUnitTypeId=3&bookmark=12528
我需要重复这个循环180次，结果是"Request time out" error。我需要根据startDate和endDate过滤记录，没有提到可以根据startDate或endDate对数据进行排序的排序标准。有人能帮我找出对这些数据进行排序的方法吗？或者告诉任何其他API可以进行这种类型的排序吗？
注意：所有18000条记录都具有属性"IsActive":true
与其按用户获取组织单元列表，不如尝试按组织单元列表获取用户。您可以尝试使用/d2l/api/lp/{ver}/orgstructure/{orgUnitId}/descendants/?ouTypeId={courseOfferingType}来检索从用户注册的最高共同祖先派生的课程提供ID的整个列表。然后，您可以循环使用/d2l/api/lp/{ver}/courses/{orgUnitId}来获取每个组织单元的课程提供信息，以预过滤并根据日期删除所有您不关心的课程提供。然后，对于剩下的那些，您可以检查用户在其中每一个中的注册情况，以确定用户与您的较小集合中的哪一个匹配。
这肯定会导致对服务的更多调用，而不是更少，所以它只有两个优点：
-
您应该能够从一开始就获得所需的全部课程，而不是将其放回页面中（尽管这个调用在未来完全有可能变成一个分页调用，以及它目前不赞成的"一次获取所有组织单元"性质）。
-
如果您需要为多个用户执行整个用例，您可以提取组织结构数据一次，缓存它，然后只对数据子集上的用户执行查询。
同时，我认为请求增强注册呼叫以提供更好的过滤（活动/非活动、开始日期、结束日期等）是完全合理的：我怀疑这样的请求可能比请求控制客户端的寻呼（即每个页面帧中的响应数）更具吸引力。