Data types for HTTPRequest and HTTPStreamRequest are hardcoded today. Because of #288, we need to support generics for data. They default to backwards compatible types.
Description
This PR makes the following backwards compatible changes:
HTTPRequest now takes a type parameter that is applied to data. It defaults to QueryRequest.
HTTPStreamRequest now takes a type parameter that is applied to data. It defaults to StreamRequest.
Motivation and context
To take advantage of HTTPClient.request against endpoints other than /query/v1, we need to support payloads other than QueryRequest. While we don't have an immediate use case for extending HTTPStreamRequest, I would argue it makes sense to keep the approaches the same across our two primary request types (call/response and streaming).
How was the change tested?
No tests were added for this specific change. If all existing tests pass, this is a safe change. The underlying data types are never referred to or accessed directly within the client.
Screenshots (if appropriate):
N/A
Change types
[ ] Bug fix (non-breaking change that fixes an issue)
[x] New feature (non-breaking change that adds functionality)
[ ] Breaking change (backwards-incompatible fix or feature)
Checklist:
[x] My code follows the code style of this project.
[ ] My change requires a change to Fauna documentation.
[ ] My change requires a change to the README, and I have updated it accordingly.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.
ecooper
commented
4 weeks ago
Data types for
HTTPRequestandHTTPStreamRequestare hardcoded today. Because of #288, we need to support generics fordata. They default to backwards compatible types.Description
This PR makes the following backwards compatible changes:
HTTPRequestnow takes a type parameter that is applied todata. It defaults toQueryRequest.HTTPStreamRequestnow takes a type parameter that is applied todata. It defaults toStreamRequest.Motivation and context
To take advantage of
HTTPClient.requestagainst endpoints other than/query/v1, we need to support payloads other thanQueryRequest. While we don't have an immediate use case for extendingHTTPStreamRequest, I would argue it makes sense to keep the approaches the same across our two primary request types (call/response and streaming).How was the change tested?
No tests were added for this specific change. If all existing tests pass, this is a safe change. The underlying data types are never referred to or accessed directly within the client.
Screenshots (if appropriate):
N/A
Change types
Checklist:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.