Add an interface for the HTTP response

[mhoeger]

We should add a TypeScript interface for an HTTP response object. This gets tricky because we support both express-like and http-module-like ways of crafting a Response.

See discussion here:
#160

[IGx89]

Would love this! Also, FYI, currently the response object is defined as optional which seems to be incorrect according to discussion in #160. It misleading suggests that if (!context.res) { ... } is a valid way to check if a response has been set, which isn't.

[mhoeger]

@IGx89 - the response object is optional because in non-HTTP scenarios, there is no context.res (ex: functions that are queue-triggered, cosmos DB-triggered, event grid-triggered, etc.). But you are right that the res object is always there for HTTP scenarios (which is most common for JS developers), and that function code should never be checking if (context.res)

[IGx89]

Ha, good point! Completely forgot about the non-HTTP scenarios. If you don't mind me asking here, what is the proper way to check if an HTTP response (context.res = {}) has already been set or not?

[ShawnTalbert]

@IGx89 - the response object is optional because in non-HTTP scenarios, there is no context.res (ex: functions that are queue-triggered, cosmos DB-triggered, event grid-triggered, etc.). But you are right that the res object is always there for HTTP scenarios (which is most common for JS developers), and that function code should never be checking if (context.res)

Is there a reason we're not considering interface inheritance for this?

As an aside, perhaps this is a bit of a design smell around the abstraction function bindings are attempting to provide.

[fabiocav]

@mhoeger do you have an update on this item?