Attempting to define how middleware is dispatched.
5.2 Delegate Design
The DelegateInterface defines a single method that accepts a request and
returns a response. The delegate interface must be implemented by any middleware
dispatcher that uses middleware implementing ServerMiddlewareInterface.
Obviously, dispatching a middleware does not necessarily implies the existence of a next available middleware or a next middleware component. There are too many real-world use-cases where we want to dispatch only one single middleware; hence, sticking to the current phpdoc wording would make PSR-15 less useful and does not reflect the point of view of the README.md.
Moreover PSR-15 should focus on interop of middlewares, the existence of additional middlewares in some frameworks is therefore out of scope. A middleware should only be aware of sitting between a request and a response. Using the StackPHP picture:
Why Process and not Dispatch at DelegateInterface?
This is due to the fact, that we currently have DelegateInterface::process and not DelegateInterface::dispatch.
Why request processor?
This is also due to the fact, that we currently have DelegateInterface::process and not DelegateInterface::dispatch or DelegateInterface::handle – In my opinion, request handler sounds much better and is more common, but there is no reason to introduce another technical term. Furthermore, obviously, a standard should use as few technical terms as possible to not confuse implementers.
Form the current
README.mdObviously, dispatching a middleware does not necessarily implies the existence of a next available middleware or a next middleware component. There are too many real-world use-cases where we want to dispatch only one single middleware; hence, sticking to the current phpdoc wording would make PSR-15 less useful and does not reflect the point of view of the
README.md.Moreover PSR-15 should focus on interop of middlewares, the existence of additional middlewares in some frameworks is therefore out of scope. A middleware should only be aware of sitting between a request and a response. Using the StackPHP picture:
Why Process and not Dispatch at
DelegateInterface?This is due to the fact, that we currently have
DelegateInterface::processand notDelegateInterface::dispatch.Why request processor?
This is also due to the fact, that we currently have
DelegateInterface::processand notDelegateInterface::dispatchorDelegateInterface::handle– In my opinion, request handler sounds much better and is more common, but there is no reason to introduce another technical term. Furthermore, obviously, a standard should use as few technical terms as possible to not confuse implementers.