Student wiki assignment—Accessing the creator of a page via API

[ryan_schram]

I have an assignment for my classes in which students create and edit pages within a Group for the class, like a wiki or knowledgebase. To track their contributions, I am accessing the Group via the API and getting a list of Pages, and for each Page getting a list of the PageRevisions. PageRevisions include the name of the student who made the edit and the date. But the Page object does not seem to include a "created_by" attribute.

So I can track students' edits to existing Pages but if one creates a new Page and adds some initial content to it, I can see that as a change when I query the Group via API request, but I can't see the original author of the page. In other words, I can track when students edit pages but not when they create pages.

(1) Does the initial creation of a page get represented as a PageRevision?

(2) If not, and it appears from the students' work so far that the answer is no, then is there another way to use the API to collect their activity on the shared Pages, including both creation and editing of Pages.

Thanks in advance. 🙂

[James · Accepted solution]

@ryan_schram 

If I create a new wiki page and list revisions, that initial creation has revision_id=1 and lists the page creator under the "edited_by" property.

I tested it under the course wiki page rather than the group wiki page, but it should return similar results.

[ryan_schram]

This appears to be correct on my end as well. So that means that I can track all student contributions by requesting a list of PageRevisions for a Page.

A new problem has emerged. My request for a list of Pages returns an incomplete list of the Pages in a Group, and the list of PageRevisions is also incomplete. The list of Pages seems to be sorted in ascending order by date of creation and stops at the 10 oldest pages. The list of PageRevisions for each Page is also limited to 10, but is sorted in reverse chron order.

I think this is because the default for any GET request on the API is 10 and that results are "paginated." (I did something similar to this in 2020. Apparently don't have the script I used then but I'm starting to remember this problem.)

This isn't really clearly noted in the API doc pages for Pages and PageRevisions. It's a classic case of terse style of technical documentation. Given that Canvas users are a more diverse group with different levels of technical competence (compared to, say, Perl mongers on a pm.org listserv), I suggest making this clearer and more descriptive, linking back to the doc pages about the arbitrary default limit on 10 items in a request, and expanding this as well. Also, while I don't understand the technical reasons (beyond the need to conserve compute resources) for limiting a GET request of this kind, I wish it wasn't arbitrarily limited because it makes a simple use of the API (getting all of the PageRevisions for a Page or all of the Pages) unnecessarily difficult. Why would you ever want the first or last 10 of changes?

This discussion post is a good guide to a pattern for handling pagination of results of unknown length. (Thanks to whomever wrote it.)

https://community.canvaslms.com/t5/Canvas-Developers-Group/Handling-Pagination/td-p/51450

It would be a good basis for a tutorial.

[James]

@ryan_schram 

You're running up against pagination, which is explained in the API documentation. Almost all requests are limited to 10 items unless you specify a different value. It makes network requests faster if you don't have to download all the results. It's designed for interactive use where you cannot be waiting around.

The quickest fix is to add ?per_page=100 to the end of your URL. That will give you the first 100 revisions. The 100 is not "a large number", most are capped at 100 even if you specify more. I see people put per_page=500 but that shows they don't really understand what's going on because it's only going to give them 100.

If you have more than that, then the pagination documentation will help, but it likely will be as simple as adding ?per_page=100&page=2 or ?per_page=100&page=3 to the end of the request.

The official way is to check the headers for the presence of a next link, but it will probably work here.

[sendres]

As @James noted, the best way to make sure you get all the entries is to check the Links header after each response. I'm not sure what programming language you're using, so here's some pseudocode on how I usually do this:

entries = <initialize_an_empty_list>

url = <url_to_get_the_first_10_responses>

while url:

    responses = request(url)

    for response in responses:

        entries += response

   try:

        url =  response.links['next']['url']

    except:

        break

 Hope this helps!