PHP Dove terminano i percorsi e iniziano le query

2

Ho un'app PHP e il 90% del codice riguarda la gestione di più tabelle MySQL. Ma ci sono altri sistemi come un sistema utente e un sistema di amministrazione, ecc. Tutte le richieste PHP vengono elaborate in un unico file app, quindi questo file deve inviare i comandi richiesti e inviare i parametri. La domanda è: dove inizia il routing e i parametri? Si prega di capire che non ho accesso al file httpd.conf in modo che non possa fare il routing reale. Questo è il routing simulato. Prendi questo esempio

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

o

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

Quindi la prima via è facile

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;
   }

}

Il mio dilemma di progettazione è quando ho finito il routing e quando inizio ad elaborare i "comandi"? Ad esempio, se ci sono 20 tabelle il tableRoute è tecnicamente ancora in routing alla tabella successiva e il comando non è ancora stato elaborato. Quindi la query route dovrebbe essere

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

dove il percorso è correttamente scappato? Oppure il percorso finisce al primo percorso. Ho anche visto persone usare la seconda parte del percorso, dopo la barra, come comando, quindi forse dovrebbe essere

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

    
posta BarryBones41 06.04.2016 - 18:58
fonte

1 risposta

3

Consiglierei di nascondere di più sull'implementazione della tua app da parte dell'utente finale, in parte perché dà meno informazioni agli utenti nefandi e anche in modo da poter implementare l'accesso ai dati e la generazione di risposte nel modo che rende più senso, piuttosto che essere vincolato dalla struttura dell'URL.

Direi che dovresti avere un parametro route che è più o meno equivalente al tuo attuale parametro tableName . Quindi disponi di un parametro action che sarebbe come il tuo attuale parametro cmd , quindi id e sort possono funzionare esattamente come li hai.

A proposito, non si dovrebbe mai e poi mai inviare testo in chiaro (o qualsiasi altra cosa, se può essere aiutato) le password come parametri di query. È così facile usare a <form method="POST" ...> che non c'è mai una ragione per non usarlo. Anche se non sembra importante ora è importante prendere l'abitudine di farlo nel modo giusto ogni volta.

Ecco alcuni esempi basati sul tuo:

site.com/app.php?route=user&action=login (con parametri POST nel corpo della richiesta)

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

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

    
risposta data 06.04.2016 - 19:54
fonte

Leggi altre domande sui tag