How far should the standard interface options go?

[analog-nico]

I am wondering if the list of interface options may already be too much.

For example:

• body taking streams may be better suited as part of streams extension that is loaded as an optional dependency
• gzip, cookie, proxy, and tunnel are something that should be loaded as a dependency.

I am not sure if I get the purpose of the options right. Maybe the spec does not intend that all option are actually available with each implementation. Rather if it is then the options work in the specified way.

[simov]

Yes you are correct, almost every option will be published in separate module. Each module should expose common interface of course. I'm actually half way through migrating all modules that are currently bundled in @request/core into separate modules. Having all options as separate modules will allow us to include them in a consistent way, and of course the main benefit will be that each option can have additional third party dependencies in it.

[analog-nico]

That is absolutely awesome @simov !

Then I would suggest that some of the options will be marked as "minimum". If someone wants to write his own implementation of the interface he would need to support all "minimum" options/features. I think that could be these:

• url/uri
• qs
• form
• json
• body (just for Array and String input)
• encoding
• headers
• length
• callback
• timeout

For all other options the library would need some kind of inspection to check if that feature is supported by the implementation that it got injected. I would suggest:

request.supports('gzip') // -> true/false

This inspection doesn't seem so easy to specify to me yet. In the case of gzip some implementations may support more or less different gzip algorithms. So the .supports(...) function may need to return more detail.

But I leave it at that for now in case I digressed to much from the purpose of the spec.

[simov]

Yep my initial idea was exactly that. However my idea with this spec is to only say what the interface options should be. I'm not trying to say how these options will be implement, or whether they should be implemented at all. I'm only saying that following this spec will give you certain flexibility with your implementation and you will be able to use other modules build around that spec.

For example you as implementator can create much more sophisticated HTTP client for your users, including the supports method.

Another example would be that I'm going to create a @request/legacy HTTP client that follows this spec, and includes all available @request/modules, and enables all available options by default. Just for backward compatibility.

Also I just updated the docs and added TOC at the top. Take a look at the Promises examples and #3