Interface AsyncRequestBody

All Superinterfaces:
org.reactivestreams.Publisher<ByteBuffer>, SdkPublisher<ByteBuffer>
All Known Subinterfaces:
CloseableAsyncRequestBody, SubAsyncRequestBody
All Known Implementing Classes:
AsyncRequestBodyListener.NotifyingAsyncRequestBody, BlockingInputStreamAsyncRequestBody, BlockingOutputStreamAsyncRequestBody, BufferedSplittableAsyncRequestBody, ByteBuffersAsyncRequestBody, ChecksumCalculatingAsyncRequestBody, CompressionAsyncRequestBody, CrtContentLengthOnlyAsyncFileRequestBody, FileAsyncRequestBody, InputStreamWithExecutorAsyncRequestBody, NonRetryableSubAsyncRequestBody, RetryableSubAsyncRequestBody

@SdkPublicApi @SdkAdvancedApi(cautionWhen=IMPLEMENTED, guidance="This is a reactive-streams Publisher and must obey the reactive-streams specification. The SDK re-subscribes on each retry attempt, so to support retries, reproduce the full content on every subscribe; a body that cannot should fail the subscriber on a later subscribe rather than emit partial content.", saferAlternative="Prefer the AsyncRequestBody.fromFile/fromBytes/fromInputStream factories. If you must supply a custom Publisher, build it with an established reactive-streams library such as RxJava or Reactor rather than implementing Publisher by hand.") public interface AsyncRequestBody extends SdkPublisher<ByteBuffer>
Interface to allow non-blocking streaming of request content. This follows the reactive streams pattern where this interface is the Publisher of data (specifically ByteBuffer chunks) and the HTTP client is the Subscriber of the data (i.e. to write that data on the wire).

Publisher.subscribe(Subscriber) should be implemented to tie this publisher to a subscriber. Ideally each call to subscribe should reproduce the content (i.e if you are reading from a file each subscribe call should produce a Subscription that reads the file fully). This allows for automatic retries to be performed in the SDK. If the content is not reproducible, an exception may be thrown from any subsequent Publisher.subscribe(Subscriber) calls.

It is important to only send the number of chunks that the subscriber requests to avoid out of memory situations. The subscriber does it's own buffering so it's usually not needed to buffer in the publisher. Additional permits for chunks will be notified via the Subscription.request(long) method.

See Also: