I have noticed some areas where we're regularly having to call GETs per-object that I think could be reduced by introducing collection-based endpoints, which I think would be nice to see in a future API version to optimize things further:
- /Jobs/{jobId}/SelectedItems and ExcludedItems - ideally, we'd like to be able to do a query like /Jobs/SelectedItems that then maps the returned array to the jobId so we don't have to make 2 API calls per job on each server. We don't often directly edit jobs in the VB365 console, but it does happen sometimes, and we don't want the configurations to get out of sync, in part because we're essentially using our portal's database as a configuration backup for VB365 jobs since there isn't the native capability.
- /JobSessions/{sessionId}/ProcessedObjects - we sometimes have 50 or more job sessions running at a time on our larger server. Paired with periodic syncs to surface progress in the UI every few minutes, this can result in hundreds or thousands of additional API calls that could be consolidated with a single /JobSessions/ProcessedObjects call with upper and lower bound DateTime restrictions like /JobSessions has.