API Per Page Limits

[Cody Cutrer]

Just as a friendly announcement, Instructure will be adjusting the per_page default and maximum allowed over the next few days. There isn't a set number on either we're aiming for, but we've heard your pains, and want to open up the throttle a bit, so to speak. We'll be monitoring our systems, and hopefully getting to a number that works better for both the server and API consumers.

Cody Cutrer

Software Engineer

Instructure

[Becky Kinney]

Thanks! It really helps to be in the loop. I'm thinking (hoping) that my current calls will continue to work no matter what the new max or defaults are, but I will still be keeping a sharp eye out. I set my per_page to 50 on every initial request, and then adjust it on the follow-up request if I see a second page and fewer than 50 records. So far that has worked out okay, no matter which endpoint I've hit. Hopefully all I need to do once the dust settles is switch from 50 to the new max?

Becky

--
 
---
You received this message because you are subscribed to the Google Groups "Canvas LMS Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to canvas-lms-use...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
Becky Kinney

Academic Technology Services

[Cody Cutrer]

Becky,

Thanks for the feedback. Actually, it would be helpful to us if you adjust your initial per_page to the most *you're* willing to handle. Otherwise, when I push the limit to over 50, I won't see any change, cause it's being limited by your request.

Cody Cutrer

Software Engineer

Instructure

[Ryan Hiebert]

Awesome! This should significantly drop the number of requests I make.

[Michael Rowe]

That's great! I really appreciate Instructure listening to its users. I think this will really help the API's usability.

[Becky Kinney]

Will do, but I don't really know how to decide how many I should be willing to handle. Any suggestions? I've sort of been assuming that fewer requests is always better. Not so? 

[Cody Cutrer]

Becky,

It depends on your app. For example, if you are only going to be showing 10 items in your UI, cause that's all that can fit, ask for 10 (or 11, if you want to be able to show a "there are more items" link. If you're doing some sort of processing, you may only want to keep a few hundred in memory at a time, so ask for that many. If you're sure that you can fit everything in memory (and it's useful to do so), go ahead and ask for 1000 or so. From your app's perspective, fewer requests is better. From the server's perspective, we have to balance fewer requests with expensive requests having impact on others, so will adjust the max as needed to meet those demands.

Cody Cutrer

Software Engineer

Instructure

[Ryan Hiebert]

I find that my constraints are related to memory. So I've set mine at 2000. I figure that they're unlikely to ever push it that high, but if they did, I think I'd want to take advantage of it. In my application, the number of requests is the limiting factor in its performance, so less requests is better for me.

Sent from my iPhone

[Becky Kinney]

2000 sounds good to me. I don't think I have any test cases to try that come close to that. I'm not pulling data for my entire university at any one time; at most, one course's worth of assignment submissions. Hopefully I'm never going to hit up against a memory ceiling. I certainly hope not. Currently I'm collecting everything before I start processing my data, so if memory becomes an issue, I'll need a serious redesign.

[Ryan Hiebert]

For your knowledge, pulling all data is  pretty much what I'm doing. In that case, the bigger the better.

Sent from my iPhone

[jared...@gmail.com]

Cody, the https://$domain/api/v1/courses/$courseID/students/submissions?$userIDs Api still only accepts 50 userIDs. If I ask for more I get a message saying it is unauthorized.

Any chance that we can open that up to take more, maybe 300 userIDs?

Jared

[Cody Cutrer]

Jared,

I'll do you one better. If you pass students_ids[]=all (as described in https://canvas.instructure.com/doc/api/submissions.html#method.submissions_api.for_students), it will give you all students you have access to. Then you only have to worry about paginating the submissions, and not the students.

Note that the error for more than 50 ids is new, but the limit is not. It used to silently drop them, probably not returning data it should have, and you would have had no idea. I fixed that, and introduced the 'all' special id at the same, with you in mind :)

Cody Cutrer

Software Engineer

Instructure

--

[jared...@gmail.com]

Wonderful!

[jared...@gmail.com]

It worked, it let me cut out about 40 lines of code and cut out about 20 seconds of load time. Thank you so much.

[Randall Anderson]

Cody,

Have you come up with a hard number of returns yet? We could use more than 50, but I don't want to involve my API programmers in trail and error, so if you have a hard number of returns we can adjust our interface to that number.

Thanks, Randy

[Cody Cutrer]

Randy,

There will never be a hard number. Instructure reserves the right to change the limits at any time. That said, you should be asking for whatever YOU want - say 100, 150, 200, 1000? - regardless of the current limit. And then your code should be tolerant of getting less than that back, and following the link headers. If we open it up more, your app will immediately benefit.

Cody Cutrer

Software Engineer

Instructure

--

---
You received this message because you are subscribed to the Google Groups "Canvas LMS Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to canvas-lms-use...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Randall Anderson]

Ok, got it!

Thanks








1

--

Respectfully Serving
-- 
Randall Anderson M.Ed.

Programming Analyst Instructional Systems
Maricopa Community Colleges
---
Office: 480.731.8072