You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Aug 13, 2026. It is now read-only.
Repository navigation
This repository was archived by the owner on Aug 13, 2026. It is now read-only.
API differences between HTTP and gRPC implementations #154
We have two methods of interacting with the API backend: gRPC (default) and HTTP (used when client is created with google.cloud.logging.Client(_use_grpc=0) or DISABLE_GRPC is set).
This is implemented using two _*API implementations: One in _http.py and the other in _gapic.py. It looks like in some cases, they return different values (_http returns a page iterator object directly, while _gapic often converts it to a generator. This confuses users who expect high-level APIs to act consistently regardless of the implementation used.
I suggest we refactor _http.py to be consistent with _gapic.py, and add tests to make sure they act consistently
FYI @daniel-sanche, there is work underway for GAPIC to have a fallback http transport. See doc. It should eventually be possible to remove the handwritten HTTP implementation and just maintain the wrapper around GAPIC.
Good to know. For the v3 release, we should make sure the APIs are compatible, but we should avoid investing too much time in the hand-written code and plan to use the gapic code instead
Activity
busunkim96 commentedon Jan 22, 2021
FYI @daniel-sanche, there is work underway for GAPIC to have a fallback http transport. See doc. It should eventually be possible to remove the handwritten HTTP implementation and just maintain the wrapper around GAPIC.
daniel-sanche commentedon May 19, 2021
Good to know. For the v3 release, we should make sure the APIs are compatible, but we should avoid investing too much time in the hand-written code and plan to use the gapic code instead