<table role="table">
<thead>
<tr>
<th>Q</th>
<th>A</th>
</tr>
</thead>
<tbody>
<tr>
<td>Bug report?</td>
<td>no</td>
</tr>
<tr>
<td>Feature request?</td>
<td>no</td>
</tr>
<tr>
<td>BC Break report?</td>
<td>no</td>
</tr>
<tr>
<td>RFC?</td>
<td>yes</td>
</tr>
<tr>
<td>Symfony version</td>
<td>3.4 and\or 4.0</td>
</tr>
</tbody>
</table>
<p dir="auto">Hi, I'm currently working on some kind of RPC server bundle stack on top of symfony and I have a simple internal method routing, which generally repeats the symfony one's. I say repeats but not re-uses (which I hope to do initially), since the current routing have several limitations:</p>
<ul dir="auto">
<li>
<p dir="auto"><a href="https://github.com/symfony/symfony/blob/master/src/Symfony/Component/HttpKernel/Controller/ControllerResolver.php">Controller Resolver</a> signature requires the whole <code class="notranslate">Request</code> object, but really it uses only <code class="notranslate">_controller</code> attribute value, can we pass it instead? The <code class="notranslate">Request</code> object is used only to build Exception message with <code class="notranslate">getPathInfo</code> call, but I think we can overcome it with rethrow on higher level or just refactor it out. Most of the exceptions, thrown by <code class="notranslate">ControllerResolver</code> do not use the <code class="notranslate">PathInfo</code> to construct the message.</p>
</li>
<li>
<p dir="auto"><a href="https://github.com/symfony/symfony/blob/master/src/Symfony/Bundle/FrameworkBundle/Controller/ControllerNameParser.php">Controller Name Parser</a> signature hardcodes the <code class="notranslate">Controller\*Controller::*Action</code> controler layout and it is even not configurable. Replacing this layout to another (or making this configurable) leads to full class override with copy&amp;paste despite of the fact it is open for inheritance. we can make action guessing and action parsing to be protected methods, which define the layout</p>
</li>
</ul>
<p dir="auto">I also have some thoughts on decoupling <code class="notranslate">Route</code> from HTTP since most of the routing loading process could be fully reused for creating internal routing, but the current <code class="notranslate">Route</code> class is all about HTTP routing (i.e it <a href="https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Routing/Route.php#L159">modifies path to match URI format</a>), but I haven't fully formalized this thoughts yet</p>
<p dir="auto">I hope we can make the components a bit more decoupled with this ideas.</p>
<p dir="auto">WDYT?</p>
<p dir="auto">There's no point in naming <code class="notranslate">$_GET</code> <code class="notranslate">$request-&gt;query</code> and <code class="notranslate">$_POST</code> <code class="notranslate">$request-&gt;request</code>. They should be called <code class="notranslate">$request-&gt;get</code> and <code class="notranslate">$request-&gt;post</code>, simply. While I could understand in <em>theory</em> how <code class="notranslate">query</code> is more correct (RFC et al) but this is a PHP app, the parsed query string is called <code class="notranslate">get</code> and that's it.</p>
<p dir="auto">But I can't fathom the logic where naming <code class="notranslate">$request-&gt;post</code> after another <em>existing</em> superglobal (<code class="notranslate">$_REQUEST</code>) would make any sense. Someone suggested that perhaps it's named after request body. But <em>that</em> should be $request-&gt;input because <code class="notranslate">php://input</code>.</p>
<p dir="auto">These could be, for the sake of BC, just references. Very easy fix: add <code class="notranslate">get</code> and <code class="notranslate">post</code> property, document it, add reference-value in constructor, done.</p>