I’m currently developing an iOS app that integrates with Google Drive API without using the official Objective-C SDK. I’ve successfully implemented file modifications using both “media” and “multipart” upload types. The media type works fine for updating just file content, while multipart handles both content and metadata updates perfectly.
However, I’m struggling with implementing the “resumable” upload type for file updates. According to Google’s documentation, regular file updates use PUT requests, but resumable uploads seem to work differently. The process appears to require an initial POST request to send only the file metadata, followed by a separate PUT request for the actual file data.
This two-step approach is confusing me and I can’t get it working properly. Has anyone successfully implemented resumable file updates with Google Drive API? Any guidance on the correct request sequence would be greatly appreciated.
Had the same problem when I built resumable uploads for file modifications last year. The trick is including the file ID in your initial POST URL: https://www.googleapis.com/upload/drive/v3/files/{fileId}?uploadType=resumable instead of the regular files endpoint. Keep the metadata minimal in that first POST - only include what you’re actually changing. Then your PUT requests send the file content in chunks with proper Content-Range headers. Watch out though - the session URI from the initial POST expires pretty quickly, so don’t wait around to start uploading. Also, if your file isn’t huge, resumable uploads might be overkill compared to the multipart approach you’ve already got working.
resumable updates are definitely weird compared to regular uploads. you’re overcomplicating it tho - just use PATCH for your initial metadata request instead of PUT, then send your PUT chunks normally. the session url works exactly the same. don’t overthink the two-step process - it’s basically identical to new file uploads after that first response.
Hit this exact problem six months back on a similar project. I was treating resumable file updates like brand new uploads - that’s where I went wrong. You’ve got to POST to the specific file endpoint with the file ID, but here’s the kicker: include the original file’s metadata even if you’re not changing anything. The API expects certain fields during that initial handshake. Also, handle partial failures right. If your PUT craps out halfway through, query the upload status with a Content-Range header (no body) to see what actually made it through. Saved me hours when testing on sketchy connections. Make sure your Content-Length in the initial POST matches exactly what you’re uploading later, or you’ll get weird 400 errors.