Add blob option to zcapClient.request() and update unit test#27
Add blob option to zcapClient.request() and update unit test#27dmitrizagidulin wants to merge 1 commit intodigitalbazaar:mainfrom
Conversation
…the new option Signed-off-by: Omar Salah <omar.salah1597@gmail.com>
| * @param {object} options.json - The JSON object, if any, to send with the | ||
| * @param {object} [options.json] - The JSON object, if any, to send with the | ||
| * request. | ||
| * @param {Blob|Buffer|Uint8Array} [options.blob] - The binary blob to send |
There was a problem hiding this comment.
Seems like this should perhaps be named body. Thoughts? I would also say that {Blob|Uint8Array)} would suffice, since a Buffer is a Uint8Array.
There was a problem hiding this comment.
Understood, yeah. So, part of the challenge here is that -- the fetch parameter for BOTH JSON and any other payload is named body. But ky made a syntactic shortcut field json that was short for "body: & content-type: json", right.
So, my thought with naming this param blob is to to use the same pattern -- have that stand for a shortcut of "body: & content-type: octet-stream".
I'm happy to drop that and just pass body through, though.
There was a problem hiding this comment.
I think passing in body is what we should do -- and if you pass both json and body it's an error (which hopefully ky handles on its own already, I don't recall).
Notably, a Blob can have a totally different content-type than just octet-stream (as a Blob can carry its own media type as an option). If we accept either json (for backwards compatibility/compatibility with ky) or body, where it can be a Blob or Uint8Array -- and we don't allow both, I think we'll have our bases covered without introducing yet another option that isn't in sync with either fetch or ky.
Then, when body is a Uint8Array, the content-type will have to be manually set (or default to octet-stream) and if it's a Blob instance, the content-type can be pulled from the Blob or default to octet-stream.
Unless I'm missing some other problem, it seems body would work fine and would be more future proofed in the event there are other body "types", with only json having been special cased.
dlongley
left a comment
There was a problem hiding this comment.
Starting making suggestions, but there are lot -- probably easier to do find and replace for blob => body.
Also, I didn't check the headers here, presumably, ky / httpClient handles them by using application/octet-stream if nothing else is provided.
| * @param {object} options.json - The JSON object, if any, to send with the | ||
| * @param {object} [options.json] - The JSON object, if any, to send with the | ||
| * request. | ||
| * @param {Blob|Buffer|Uint8Array} [options.blob] - The binary blob to send |
There was a problem hiding this comment.
| * @param {Blob|Buffer|Uint8Array} [options.blob] - The binary blob to send | |
| * @param {Blob|Uint8Array} [options.body] - The binary blob to send |
| headers = {}, | ||
| json | ||
| json, | ||
| blob |
| // handle blob vs json body | ||
| if(blob !== undefined) { | ||
| options.body = blob; |
There was a problem hiding this comment.
| // handle blob vs json body | |
| if(blob !== undefined) { | |
| options.body = blob; | |
| // handle binary body vs json body | |
| if(body !== undefined) { | |
| options.body = body; |
Updates the
request()method to also support binary Blob objects in request body (in addition to just JSON object).