Revisit method of passing responseType

natevw / fermata

Succinct native REST client, for client-side web apps and node.js. Turns URLs into (optionally: magic!) JavaScript objects.

328 stars 24 forks source link

Revisit method of passing responseType #51

Closed natevw closed 8 years ago

natevw commented 10 years ago

I think it's clear that this needs to be controllable. What's not clear is if the right solution is:

expose only to plugins (they have the "internalish" request object to set it on…but this would be the only option not also exposed via the "main" API)
expose as a new argument (as currently on 'upcoming' branch)
expose via X-Fermata-ResponseType header (c.f. #36)

Almost leaning towards the latter at the moment…

natevw commented 10 years ago

Another idea: "annotated" callbacks, e.g. url.post(data, fermata.stream(cb))

Meta-idea: a plugin can change req.responseType on its way to a transport. Perhaps first figuring out how plugins can get mixed-in later (#30) and then revisiting streams/promises would be a better design approach.

natevw commented 9 years ago

This might be an event better idea: add an opts param to the left of headers. This might be the most general-purpose way, since putting things like this into 'X-Fermata-' headers ends up being frustratingly verbose. (This might also help address things like https://github.com/natevw/fermata/issues/16 and https://github.com/natevw/fermata/issues/31 and https://github.com/natevw/fermata/issues/49 and perhaps even https://github.com/natevw/fermata/issues/30…)