DASPRiD
commented
10 years ago @bakura10 A mismatch in query keys does not require a specialized response, as HTTP does not know a proper response code for that, so you simply return a generic failure. As to why to have method matching in the router, it's up to the user to decide where he wants to handle that. There are many routers in many languages out there which handle method routing, simply because it's part of the request. Here's a far fetched different use-case: You want to intercept GET requests to a 3rd party module, but let itself still handle the POST request (or the other way around). You can very easily do this now.
I'm not sure to fully understand the whole thing yet, but for now I'm not a big fan. Which advantage should that bring? Can't you simply have a simple "SuccessfullMatch" and "FailureMatch" with a simple "type" hint, à la AuthorizationResult? I mean, by defining those classes, what if we want to introduce a set of "allowed query keys"? Should we then create another "QueryMismatchResult"? That seems a bit overkill to me.
Furthermore, in things like REST (AbstractRestfulController, my own ZfrRest controllers, and I suppose Apigility too), the HTTP methods are defined on the controller (put, get...) and that's likely the controller that decide if an action can be dispatched, hence making this thing pretty useless in most cases.
Let's try not to push too many responsibility to the router, imho.