Aiogoogle doesn't support the beta Drive Labels API

[Phil305]

Hello, thanks for the great tool 🙂

I've run into an issue when trying to create an API client for the Google Drive Labels API

Request

await self.aiogoogle.discover('drivelabels', 'v2')

Response

Not Found

Content:
{'code': 404,
 'message': 'Requested entity was not found.',
 'status': 'NOT_FOUND'}

Request URL:
https://www.googleapis.com/discovery/v1/apis/drivelabels/v2/rest

I see it's in the giant JSON Google Discovery API list (grep for drivelabels:v2)

I did notice the endpoint I'm trying to use (create) in the Drive Labels API is marked as beta,
and in the JSON doc I linked above, the base URL is https://drivelabels.googleapis.com/ instead of https://www.googleapis.com/API/VERSION

I was wondering what the technical cause is for the error above?

Also, I saw a feature request for adding the option to provide custom discovery urls which looks promising (#94), would that be a work around for this issue?

Thanks!

[Phil305]

Update

I think it’s causing an error because Google uses a different root URL for the Drive Labels API (https://drivelabels.googleapis.com/ vs. https://www.googleapis.com/API/VERSION for the non-beta endpoints).

Check it out, Aiogoogle actually fetches the discovery document for the Labels API:
Request:

await self.as_anon(self.discovery_service.apis.list(name='drivelabels', preferred=None, fields=None))

Response:

{'discoveryVersion': 'v1',
 'items': [{'description': 'An API for managing Drive Labels',
            'discoveryRestUrl': 'https://drivelabels.googleapis.com/$discovery/rest?version=v2beta',
            'documentationLink': 'https://developers.google.com/drive/labels',
            'icons': {'x16': 'https://www.gstatic.com/images/branding/product/1x/googleg_16dp.png',
                      'x32': 'https://www.gstatic.com/images/branding/product/1x/googleg_32dp.png'},
            'id': 'drivelabels:v2beta',
            'kind': 'discovery#directoryItem',
            'name': 'drivelabels',
            'preferred': False,
            'title': 'Drive Labels API',
            'version': 'v2beta'},
           {'description': 'An API for managing Drive Labels',
            'discoveryRestUrl': 'https://drivelabels.googleapis.com/$discovery/rest?version=v2',
            'documentationLink': 'https://developers.google.com/drive/labels',
            'icons': {'x16': 'https://www.gstatic.com/images/branding/product/1x/googleg_16dp.png',
                      'x32': 'https://www.gstatic.com/images/branding/product/1x/googleg_32dp.png'},
            'id': 'drivelabels:v2',
            'kind': 'discovery#directoryItem',
            'name': 'drivelabels',
            'preferred': True,
            'title': 'Drive Labels API',
            'version': 'v2'}],
 'kind': 'discovery#directoryList'}

But in the error msg above, it's trying to hit an endpoint with the standard root URL: https://www.googleapis.com/discovery/v1/apis/drivelabels/v2/rest

Hopefully this can help touch on a potential fix?

[omarryhan]

Hey, thanks for raising the issue.

The simplest solution would be to manually download the API schema/discovery document and feed it to your Aiogoogle instance e.g.

from aiogoogle import GoogleAPI, Aiogoogle

def get_api():
    drivelabels_discovery_doc = await http.get("https://drivelabels.googleapis.com/$discovery/rest?version=v2")  # any http lib will do
    return GoogleAPI(drivelabels_discovery_doc)

I'll also be happy to accept a PR that resolves #94.
I was thinking it can be achieved by adding a kwarg to the discover method in Aiogoogle that instructs it to use a different URL formatter? the other formatter is for discovery service V2.

This is how the URL should be formatted for V2: https://github.com/googleapis/google-api-python-client/blob/main/googleapiclient/discovery.py#L90

"https://{api}.googleapis.com/$discovery/rest?version={apiVersion}"

Also, maybe if user doesn't pass a kwarg and V1 fetch fails to find results, maybe we can retry in V2 automatically and if that also fails, then raise an error?

[omarryhan]

This also relates to this #65

[Phil305]

PR #108 fixes this issue, so I'm closing it out; thanks so much for the help and suggestions @omarryhan 🙏🏿

[omarryhan]

Thank you! For the PR and for contributing this feature!! :)