-
Notifications
You must be signed in to change notification settings - Fork 6
Open
Description
IMHO the interface would need polishing in regard to the response handling so that alternative implementations can pop up.
First off, the callback needs to be specified in detail. It can be modelled after Request's callback definition:
The callback argument gets 3 arguments:
1. An error when applicable (usually from http.ClientRequest object)
2. An http.IncomingMessage object
3. The third is the response body (String or Buffer, or JSON object if the json option is supplied)
However, when I read this I realise that especially the second parameter is highly implementation specific. In order to make implementations replaceable we would need to define a general response object I guess.
Handling responses as a stream or a promise would ideally be loaded as an optional dependency. In particular for the promise I would define:
request({ ... })
.then(function (response) {
// All responses get resolved with the general response object I mentioned for the callback
})
.catch(function (err) {
// Equivalent to the callback getting an error
});
Metadata
Metadata
Assignees
Labels
No labels