[RestProxy] Streaming request body about autorest-clientruntime-for-java HOT 6 CLOSED

HttpRequest requires a mimeType argument be passed when setting the request body, but this is likely to come from the @Headers annotation. Will work around it for now but we'll probably want to coalesce on a standard method for handling this.

It may be desirable to take certain standard headers and give them their own required annotations so we can ensure that a service interface method is well-formed more easily.

from autorest-clientruntime-for-java.

We will want to make a design/philosophical decision about whether an HttpRequest object can be expected to be fully formed, and not need to have default values placed for missing required headers by the time RestProxy passes it to HttpClient.sendRequestAsync.

from autorest-clientruntime-for-java.

I'm also wondering if the use of InputStream is going to force us to use blocking file I/O and how that should affect the design. I think these questions might get hashed out at the time @jianghaolu is able to pull his netty adapter into the runtime.

from autorest-clientruntime-for-java.

I'm just getting to look at this, and I'm not sure that I like the idea of exposing our HttpRequest and/or HttpRequestBody classes outside of our internals. I feel that if our current annotations/annotation processing is lacking somewhere (streaming) then we should fix it there, rather than breaking our abstractions by exposing our internal data structures.
I thought that the only streaming scenario we were able to think of was streaming a file, which we already had a verbal solution for (pass in a File object and RestProxy would start streaming the file's contents as well as set the proper MIME type). Is there another scenario that has come up?

from autorest-clientruntime-for-java.

I think you’re right, although outside of this case HttpClient stuff will probably leak out of the runtime in contexts like user-defined RequestPolicies.

The file use case, which should probably be all we do for streaming until more scenarios come up, would probably be best addressed by something like what you’re describing—maybe a file path or stream, offset and length, which does whatever observable byte buffer pooling fancy thing inside. Thanks for the reminder.

from autorest-clientruntime-for-java.

This is pretty much addressed by #257

from autorest-clientruntime-for-java.