Declares the HTTP status a handler answers with when it returns a plain
value.
Without it a decorated handler is always 200: the plugin answers
ctx.response.json(result) for any return that is not already a
HandlerResult. @HttpCode(201) is what lets a create handler say 201
without accepting a request context it otherwise has no use for.
A returned HandlerResult still wins. The status is written to the
response builder BEFORE the handler runs, so a handler that returns
ctx.response.status(202).json(...) answers 202 even under
@HttpCode(201) — the explicit runtime value is the more specific
statement. It composes with @Render for the same reason: the rendered HTML
is written onto a builder that already carries the status.
204, 205 and 304 serve a bodiless response: the runtime's snapshot
mapping drops a body written at one of those statuses, which is the
conformant answer RFC 9110 §15.3.5 asks for and exactly what a DELETE
handler wants.
status must be an integer in [200, 599] — the range the web Response
constructor accepts. Anything else is refused at register(), naming the
class, the method and the value, because the alternative is a RangeError
thrown inside the adapter after the pipeline has finished, where no error
handler can answer it.
It is deliberately NOT narrowed to 2xx: a handler answering 404 through a
decorator is legitimate, and the exception hierarchy owns the error path
without monopolising the status space.
Declares the HTTP status a handler answers with when it returns a plain value.
Without it a decorated handler is always
200: the plugin answersctx.response.json(result)for any return that is not already aHandlerResult.@HttpCode(201)is what lets acreatehandler say201without accepting a request context it otherwise has no use for.A returned
HandlerResultstill wins. The status is written to the response builder BEFORE the handler runs, so a handler that returnsctx.response.status(202).json(...)answers202even under@HttpCode(201)— the explicit runtime value is the more specific statement. It composes with@Renderfor the same reason: the rendered HTML is written onto a builder that already carries the status.204,205and304serve a bodiless response: the runtime's snapshot mapping drops a body written at one of those statuses, which is the conformant answer RFC 9110 §15.3.5 asks for and exactly what aDELETEhandler wants.statusmust be an integer in[200, 599]— the range the webResponseconstructor accepts. Anything else is refused atregister(), naming the class, the method and the value, because the alternative is aRangeErrorthrown inside the adapter after the pipeline has finished, where no error handler can answer it.It is deliberately NOT narrowed to
2xx: a handler answering404through a decorator is legitimate, and the exception hierarchy owns the error path without monopolising the status space.