Enforce HttpResponse type on context.res #551
Description
This issue is related to #169. This was partially addressed in #529, which exposed interfaces to describe HTTP response types. However, this implementation is still incomplete, because these types are not actually enforced on the context.res property. As it stands, the type of the context.res property is still:
res?: {
[key: string]: any;
};Ideally, we want this to be:
res: HttpResponse;Enforcing this type is challenging is because this would be a breaking change.
The main reason is because currently we support two different and conflicting ways of return an HTTP response, both of which use the context.res property. These two ways are described in #529 and also reproduced here:
Returning a response by overriding context.res
A user can return a response by setting context.res to an object of type HttpResponseSimple, as below:
const httpTrigger: AzureFunction = async function(context: Context, req: HttpRequest): Promise<void> {
context.res = {
status: 200,
body: "hello, world",
headers: {
hello: "world"
}
}
};Returning a response using methods
The default type of context.res passed to the user's function is of type HttpResponseFull. This exposes callable functions that can be used to set the HTTP response, as below:
const httpTrigger: AzureFunction = async function (context: Context, req: HttpRequest): Promise<void> {
context.res.setHeader("hello", "world");
context.res.status(200);
context.res.body = "hello, world";
}; Challenges
If we set the type of context.res to HttpResponse = HttpResponseSimple | HttpResponseFull, we would break existing code that returns a response using the second method. #529 includes more details and suggested workarounds, but all of them would include changing code in all user-defined Functions. As far as we can tell, there is no easy way around this that doesn't require code changes to every single Function.
This issue is created to track if/when/how we want to enforce this type and make this breaking change. We could still enforce this, and have the users change their code. We could wait until there is a next major release that includes other breaking changes. Or we could decide not to enforce this type under the current programming model, and wait until the new programming model, where hopefully this issue wouldn't exist anymore.