PHP Where do routes end and queries begin

Question

I have a PHP app and 90% of the code is about managing multiple MySQL tables. But there are other systems like a User system and an Admin system, etc. All PHP requests are processed in one App file, so this file needs to dispatch requested commands and send along params. The question is, where does the routing end and the params begin? Please understand that I don't have access to the httpd.conf file so I cannot do real routing. This is simulated routing. Take this example

site.com/app.php?route=table&tableName=tableA&cmd=get&id=20&sort=asc

or

site.com/app.php?route=user&cmd=login&user=bob&pw=bobby

So the first route is easy

function route($route){
 switch($route){
 case "table":
 $this->tableRoute();
 break;
 case "user":
 $this->userRoute();
 break;
 }
}
function userRoute(){
 // its easy to stop routing here
 switch($_REQUEST['cmd']){
 case "login":
 break;
 case "register":
 break;
 } 
}
function tableRoute(){
 // but here tables need a subroute 
 // so is this where routing ends, or does routing continue?
 switch($_REQUEST['tableName']){
 case "tableA":
 break;
 }
}

My design dilemma is when am I done routing and when do I start processing "commands"? For example, if there are 20 tables the tableRoute is technically still routing to the next table and the command is not processed yet. So should the route query actually be

site.com/app.php?route=tables/tableName&cmd=get&id=9.....

where the route is properly escaped? Or does the route end at the first route. I've also seen people use the second portion of the route, after the slash, as a command, so maybe it is supposed to be

site.com/app.php?route=tables/tableName/get&id=9...

• GrandmasterB: You don't need access to http.conf to handle rewrites. You can also set them in an .htaccess file.
• BarryBones41: Oh, that's interesting..!

Answer 1

I would recommend hiding more about the implementation of your app from the end user, in part because it gives away less information to nefarious users and also so that you can implement your data access and response generation in the way that makes the most sense, rather than being bound by your URL structure.

I would say that you should have a route parameter which is more or less equivalent to your current tableName parameter. Then have an action parameter that would be like your current cmd parameter, and then id and sort can work exactly as you have them.

By the way, you should never, ever send plaintext (or any, if it can possible be helped) passwords as query parameters. It's so easy to use to a <form method="POST" ...> that there's never a reason not to use it. Even if it doesn't seem important now it's important to make it a habit to do it the right way every time.

Here are some examples based on yours:

site.com/app.php?route=user&action=login (with POST parameters in request body)

site.com/app.php?route=contacts&action=get&sort=ASC

site.com/app.php?route=movies&action=create&name=Titanic&director=James%20Cameron

• BarryBones41: So who should process the action query? Should there be a switch in (let's say) the Movies.php file that switches, or are all query params supposed to be handled by the main App including which function to run?
• Josh Rumbut: My suggestion would be for App to break the query down into an associative array like ['route' => 'movies', 'action' => 'create'...] and then pass that along to Movies.php. You could set up an interface such the Movies.php, Users.php etc all have a function called action or something similar that the array can be passed to and acted on further from there.