- From: Domenic Denicola <d@domenic.me>
- Date: Wed, 5 Nov 2014 10:01:04 +0000
- To: WHAT Working Group Mailing List <whatwg@whatwg.org>
- Cc: Yutaka Hirano <yhirano@chromium.org>
In https://github.com/yutakahirano/fetch-with-streams Yutaka, Anne, and I are working on how to integrate the fetch API with streams. The general pattern we want is that for both request and response objects their creator is given a writable stream to write body content to, using [the revealing constructor pattern][1]. (That way, for requests or responses created by the browser, developers can only read---not write---the bodies; for requests/responses created by the developer, the developer can do both.) The current fetch API when initializing with non-streaming bodies is roughly: ```js var req = new Request("http://example.com", { method: "POST", body: '{ "json": "here" }' // or blob or FormData or ... }); var res = new Response('{ "json": "here" }' /* or blob or FormData or ... */, { status: 201, headers: { 'Content-Type': 'application/json' } }); ``` Note how in both cases the "most important" value is given an unlabeled position as the first argument: requests are "about" URLs, and responses are "about" bodies. Our current thought for streams integration is to overload the "body" position for each of these with a function that takes a writable stream: ```js var req = new Request("http://example.com", { method: "POST", body(stream) { stream.write(myArrayBuffer); stream.close(); } }); var res = new Response( stream => { someCSVStream.pipeThrough(new CSVToJsonTransform()).pipeTo(stream); }, { status: 201, headers: { 'Content-Type': 'application/json' } } ); ``` Do we think this is good? Any other ideas? Personally I find the overloads weird, especially since they behave completely differently when passing a string versus passing a function. But after thinking through this for a while I didn't have any better ideas that worked for both requests and responses. [1]: https://blog.domenic.me/the-revealing-constructor-pattern/
Received on Wednesday, 5 November 2014 10:01:33 UTC