PSR-7 defines common HTTP message interfaces, and PSR-15 defines handler and middleware interfaces over them. Their value is interchangeability: middleware written against them can be shared between frameworks, and a message can be passed to any library that speaks the same interfaces.
The panel is a bespoke, purpose-built system running as a single binary on one runtime, per ADR-0009. Nothing outside it touches its messages: module authors write actions, which never see a request object.
The interfaces are also nearly a decade old, and a message built to them is shaped by that rather than by what the panel needs.
The engine defines its own request and response objects, and the contracts for handling them. It does not implement PSR-7 or PSR-15, and nothing in the panel depends on their interfaces.
Implementing PSR-7 and PSR-15, so that middleware written for other frameworks could be used. The interchangeability does not apply to a bespoke system where nothing outside the engine holds a message, and adopting the interfaces would put a dated API on every internal call site, shaping the design around the standard rather than around the panel.
No other alternative was weighed.
Easier:
Harder:
Constrained:
created and decided, and the reasons, that
PSR-7 exists so middleware can be shared between frameworks, that nothing outside the engine touches these classes
because module authors write actions, and that it would put a 2016-era API on every internal call site for no
interoperability.private(set), a request with no attribute bag, and the reasoning for it recorded in #62.