cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Community Advocate
Community Advocate

Impact of removal of Uploading Files API Call?

Jump to solution

I see from the latest release notes API Change Log that the API Call for Uploading Files API is being removed.

Will this mean that any code that has been created with this api call will no longer function?

2019-06-01
 
Removals

API Calls

Function

Uploading Files API

Uploading via POST Process

Step 3: Removed mention of POST requests in favor of GET requests for forward compatibility

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Navigator

m.mccooey@qub.ac.uk,

Sometimes you have to read closely. We tend to put emphasis where we think it should be and miss what the writer intended. What has happened is that they removed the mention of the POST requests in step 3.

I pulled up the old (current) version and the new (2019-06-01) version of the document, saved them to disk, and ran a diff command on them to see what the differences were. There were only two changes and they appear to be cleaning things up. One of them is in step 3 as they indicated, but they also changed some stuff in step 1 as well.

The first change was an addition about a second URL that you could use for posting and what the impact of posting to each would be. Everything in the first old version is in the new version, but there is additional information at the end.

For the second change, it looks like they moved the deprecation notice into a (note) rather than its own paragraph. But it says that it was deprecated on 2109-04-21, so if it is working right now, it should continue to keep working June 1.

Here are the two changes.

Old Step 1

The first step is to POST to the relevant API endpoint, depending on where you want to create the file. For example, to add a file to a course, you'd POST to /api/v1/courses/:course_id/files. Or to upload a file as part of a student homework submission, as the student you'd POST to /api/v1/courses/:course_id/assignments/:assignment_id/submissions/self/files.

New Step 1

The first step is to POST to the relevant API endpoint, depending on where you want to create the file. For example, to add a file to a course, you'd POST to /api/v1/courses/:course_id/files. Or to upload a file as part of a student homework submission, as the student you'd POST to /api/v1/courses/:course_id/assignments/:assignment_id/submissions/self/files or /api/v1/courses/:course_id/assignments/:assignment_id/submissions/comments/self/files for submission comments.

Note* The endpoint you choose to post files to will change the permissions set on the file. i.e. only files posted to the submissions comments endpoint can be attached to a submissions comment.

Old Step 3

In the case of a 3XX redirect, the application needs to perform a GET to this location in order to complete the upload, otherwise the new file may not be marked as available. This request is back against Canvas again, and needs to be authenticated using the normal API access token authentication.

[DEPRECATED] While a POST would be truer to REST semantics, and was previously called for by this documentation, a GET is recommended at this point for forwards compatibility with the 201 Created response described below. POST requests are currently supported for backwards compatibility at all endpoints that may appear in the Location header, but are deprecated effective 2019-04-21 (notice given 2018-10-06).

New Step 3

In the case of a 3XX redirect, the application needs to perform a GET to this location in order to complete the upload, otherwise the new file may not be marked as available. (Note: While a POST would be truer to REST semantics, a GET is required for forwards compatibility with the 201 Created response described below.) This request is back against Canvas again, and needs to be authenticated using the normal API access token authentication.

View solution in original post

2 Replies
Highlighted
Navigator

m.mccooey@qub.ac.uk,

Sometimes you have to read closely. We tend to put emphasis where we think it should be and miss what the writer intended. What has happened is that they removed the mention of the POST requests in step 3.

I pulled up the old (current) version and the new (2019-06-01) version of the document, saved them to disk, and ran a diff command on them to see what the differences were. There were only two changes and they appear to be cleaning things up. One of them is in step 3 as they indicated, but they also changed some stuff in step 1 as well.

The first change was an addition about a second URL that you could use for posting and what the impact of posting to each would be. Everything in the first old version is in the new version, but there is additional information at the end.

For the second change, it looks like they moved the deprecation notice into a (note) rather than its own paragraph. But it says that it was deprecated on 2109-04-21, so if it is working right now, it should continue to keep working June 1.

Here are the two changes.

Old Step 1

The first step is to POST to the relevant API endpoint, depending on where you want to create the file. For example, to add a file to a course, you'd POST to /api/v1/courses/:course_id/files. Or to upload a file as part of a student homework submission, as the student you'd POST to /api/v1/courses/:course_id/assignments/:assignment_id/submissions/self/files.

New Step 1

The first step is to POST to the relevant API endpoint, depending on where you want to create the file. For example, to add a file to a course, you'd POST to /api/v1/courses/:course_id/files. Or to upload a file as part of a student homework submission, as the student you'd POST to /api/v1/courses/:course_id/assignments/:assignment_id/submissions/self/files or /api/v1/courses/:course_id/assignments/:assignment_id/submissions/comments/self/files for submission comments.

Note* The endpoint you choose to post files to will change the permissions set on the file. i.e. only files posted to the submissions comments endpoint can be attached to a submissions comment.

Old Step 3

In the case of a 3XX redirect, the application needs to perform a GET to this location in order to complete the upload, otherwise the new file may not be marked as available. This request is back against Canvas again, and needs to be authenticated using the normal API access token authentication.

[DEPRECATED] While a POST would be truer to REST semantics, and was previously called for by this documentation, a GET is recommended at this point for forwards compatibility with the 201 Created response described below. POST requests are currently supported for backwards compatibility at all endpoints that may appear in the Location header, but are deprecated effective 2019-04-21 (notice given 2018-10-06).

New Step 3

In the case of a 3XX redirect, the application needs to perform a GET to this location in order to complete the upload, otherwise the new file may not be marked as available. (Note: While a POST would be truer to REST semantics, a GET is required for forwards compatibility with the 201 Created response described below.) This request is back against Canvas again, and needs to be authenticated using the normal API access token authentication.

View solution in original post

Highlighted

Thank you so much for your response james@richland.edu‌ which allayed my fears. The devil really is in the detail here and I clearly didn't notice that this was a mention for Step 3 only! I did ask Instructure support about this prior to posting and they gave a very different response which led to my concerns - as the functionality to bulk upload files is not available natively in Canvas some our users rely heavily on this particular api call. Thank you again for putting my mind at ease and your comprehensive response!

Maeve

Labels