gapi.client.drive.files.update() with media parameter uses wrong endpoint

[gony0089]

Summary

When calling gapi.client.drive.files.update() with a media parameter to update file content, the API returns a 200 OK success status, but the file content is not actually updated.
The root cause appears to be that the library sends the request to the standard metadata endpoint (/drive/v3/files/{fileId}) instead of the required upload endpoint (/upload/drive/v3/files/{fileId}).

Steps to Reproduce

1. First, create an empty file with only metadata using gapi.client.drive.files.create() with just the resource parameter. This step succeeds and a new fileId is returned.

2. Next, using the returned fileId, attempt to update the file's content by calling gapi.client.drive.files.update() with the media parameter.

// Minimal code to reproduce the issue
async function reproduceBug(metadata, content) {
  try {
    // 1. Create an empty file (This step works as expected)
    const createResponse = await gapi.client.drive.files.create({
        resource: metadata,
        fields: 'id'
    });
    const fileId = createResponse.result.id;

    // 2. Attempt to update the content (This step fails silently)
    const media = {
        mimeType: 'application/json',
        body: content
    };
    const updateResponse = await gapi.client.drive.files.update({
        fileId: fileId,
        media: media
    });
    
    // The API returns 200 OK, but the content is not updated.
    console.log('Update Response Status:', updateResponse.status); 

  } catch (error) {
    console.error('Error:', error);
  }
}

Root Cause Analysis

As confirmed with browser developer tools, the network request from files.update containing a media parameter is sent to the wrong endpoint:

• Expected Endpoint: /upload/drive/v3/files/{fileId}

• Actual Endpoint: /drive/v3/files/{fileId}

Because the request is sent to the metadata update endpoint, the media parameter is ignored. The request itself is valid for updating metadata (even if no metadata is changed), which is why the server returns a 200 OK response. In essence, the incorrect code is "executing successfully."

Sidenote: It appears the resource parameter works as expected for metadata-only updates, meaning the update function is currently behaving as a metadata-only update tool.

Workaround

It has been confirmed that by using gapi.client.request to manually construct a multipart upload request to the correct /upload/ endpoint, as per the official Drive API documentation, the update works as expected.

Further Analysis: Why This Issue is a "Trap" for Developers

The main reason this issue is so difficult to discover is the inconsistent behavior of the GAPI library's wrapper functions.

The files.create() function works correctly when creating an empty file with only metadata. This success creates a major "trap," leading developers to trust that the corresponding files.update() function will also work correctly for media. When it fails, most developers (99%) would not assume the library itself is at fault. They would naturally suspect their own code first:

• Is my syntax for the update function wrong?

• Am I not following the documentation correctly?

• Is this an asynchronous timing issue?

The counter-argument, "?Just read the Google Drive API documentation, it's your own fault for not doing so," is something I also considered. However, after deep investigation, I can say that the issue is a simple but critical flaw in the files.update endpoint implementation.

Why is it critical?

1. The files.update function cannot be used for its intended purpose of updating media content. This is due to the wrong endpoint.

2. The code appears syntactically correct according to GAPI conventions. Multiple AI assistants confirmed the syntax was correct.

3. AI assistants cannot identify this issue. An AI will typically suggest the simpler GAPI wrapper function gapi.client.drive.files.update() because it's easier than writing a complex raw HTTP request. Since the code is syntactically correct, the AI will not notice the underlying issue and will suggest debugging other things like the user's environment or async logic. I consulted three different AIs, and all of them failed to identify the root cause, leading to a long and fruitless debugging cycle.

It was only after exhausting all other possibilities that I came to the "presumptuous" conclusion: "Perhaps the GAPI library itself is at fault." For a beginner developer (like myself) starting a project with the assumption that AI can guide them, this kind of problem can lead to an endless dead end.

Summary of Findings:

• The server returns 200 OK because the request is sent to the wrong endpoint.

• Using the update function with media will 100% result in the request being sent to the wrong endpoint, causing the media to be ignored.

• The GAPI client library's "incorrect" code is executing "correctly" (returning 200 OK).

This is just a guess from an inexperienced developer, but I believe if the endpoint for update calls containing a media parameter were corrected, it would enable developers to use a much simpler and more intuitive method for saving files without needing to write complex code that adheres to the Drive API HTTP documentation. It seems like it would be a relatively easy fix to change the endpoint destination.

I am reporting this because I believe it is a valuable issue to address. My apologies if this is already a known issue.

Environment

• Library: Google API Client Library for JavaScript - Loaded via: https://apis.google.com/js/api.js

• Browser: Chrome Version 125.0.6422.142 (Official Build) (64-bit)

• OS: Windows 11

(This report was originally written in Japanese and translated into English using Gemini.)