Re: [whatwg] Questions about the Fetch API

From: Juan Ignacio Dopazo <jdopazo@yahoo-inc.com>

>> Why would this not be passing a writable stream object as body parameter?
>
> It would have to be a readable stream. Otherwise, how would the request be able to consume it? So most people would have to pass a stream that is both readable and writable.

Right. The creator of a writable stream can set up a relationship between the user-facing stream and the underlying source (in this case, the HTTP request body). So we have two options:

1. The fetch API creates a writable stream tied to the request body as its underlying source, and hands out a reference to that stream to the fetch API caller. Then, writes go directly from the caller to the underlying source via the stream mechanism. In this way, we have a writable stream representing the HTTP request body.
2. The fetch API accepts a readable stream from the API caller, and reads from it. As data is read by fetch, it then gets written to the HTTP request body. In this case, there is no writable stream representing the HTTP request body. If a fetch API caller wants to stream data into the request body, they have to set up a pass-through {WritableStream input, ReadableStream output} pair and pass the output to the fetch API while writing into the input. (This will likely be doable pretty easily with the streams API, perhaps via `var { input, output } = new TransformStream({ transform(x) { return x; })` or even `var { input, output } = new TransformStream()` if we add a default.)

Of these, 1 seems much nicer, based on my Node.js experience.

My first thought looking at the existing API is that FetchBodyStream is being used in two ways:

- As a request body stream
- As a response body stream

Its methods right now are geared entirely toward reading, but in reality, you write to a request body, and read from a response body. The fact that, in the current API, you can read from a request body, is actually quite bad: it means you cannot do proper fire-and-forget writes to the request socket, but instead have to do buffer-copies of everything written to the socket in case someone does readAsJSON() on the request body any time before the request body is GCed.

Thus I'd suggest renaming FetchBodyStream to ResponseBodyStream (FetchResponseBodyStream?) and introducing a new RequestBodyStream without the readAsX() methods. For now I think it'd be empty? But later it would become a WritableStream.

Does this make sense? Does it work?

Received on Monday, 14 July 2014 15:44:29 UTC