Skip to content

Conversation

@BenWhitehead
Copy link
Collaborator

  1. Define Codec<OffsetDateTime, String> to encapsulate the logic and use of date time formatter
    • Use existing RFC3339 formatter as it's already used by json and tested to be valid
    • update tests to assert equality of OffsetDateTime instances instead of strings -- this ensures that equivalent times but different strings are valid
  2. Refactor the boostrapping of MultipartUploadHttpRequestManager to be a factory method that only needs HttpStorageOptions
    • This removes the need for tests and implementation to perform manual bootstrapping multiple times unnecessarily
    • It also removes the boostrapping logic from MultipartUploadClientImpl and in turn removes the need for HttpStorageOptions to be passed around to multiple places
  3. pre-compute and have a single stable location for all headers which apply to all requests -- x-goog-api-client, x-goog-user-project, user-agent, etc
    • This makes it so fewer things need to know about and interact with HttpStorageOptions, thereby simplifying multiple methods
    • The logic and resolution happens once per client instance removing the need for redundant string concatenations, or environment probes
    • leverages existing abstractions for representing headers, and plumbs user provided headers from HttpStorageOptions
  4. Add logic to compute x-goog-api-client header to match what apiary does
  5. Update request header processing to avoid allocating a temporary map, instead add directly to the requests headers.

1. Define Codec<OffsetDateTime, String> to encapsulate the logic and use of date time formatter
   * Use existing RFC3339 formatter as it's already used by json and tested to be valid
   * update tests to assert equality of OffsetDateTime instances instead of strings -- this ensures that equivalent times but different strings are valid
2. Refactor the boostrapping of MultipartUploadHttpRequestManager to be a factory method that only needs HttpStorageOptions
   * This removes the need for tests and implementation to perform manual bootstrapping multiple times unnecessarily
   * It also removes the boostrapping logic from MultipartUploadClientImpl and in turn removes the need for HttpStorageOptions to be passed around to multiple places
3. pre-compute and have a single stable location for all headers which apply to all requests -- x-goog-api-client, x-goog-user-project, user-agent, etc
   * This makes it so fewer things need to know about and interact with HttpStorageOptions, thereby simplifying multiple methods
   * The logic and resolution happens once per client instance removing the need for redundant string concatenations, or environment probes
   * leverages existing abstractions for representing headers, and plumbs user provided headers from HttpStorageOptions
4. Add logic to compute x-goog-api-client header to match what apiary does
5. Update request header processing to avoid allocating a temporary map, instead add directly to the requests headers.
@product-auto-label product-auto-label bot added size: m Pull request size is medium. api: storage Issues related to the googleapis/java-storage API. labels Oct 23, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

api: storage Issues related to the googleapis/java-storage API. size: m Pull request size is medium.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants