Struttura della directory interna dell'API REST e RewriteEngine

Question

Struttura della directory interna dell'API REST e RewriteEngine

#1 da (2 voti)

0

Sto costruendo un'API REST. Non voglio avere real cartelle nella mia struttura di directory, ma non sono abbastanza sicuro su cosa usare. La mia API REST utilizza percorsi come questo:

api.server.com/<object>/<action>[/]

Qui, <object> è l'oggetto su cui deve essere eseguita l'azione <action> . Ad esempio, un URL api.server.com/user/create creerebbe un nuovo utente.

Per ora, ho trovato questo:

Gli oggetti hanno tutti un proprio file, come user.php per l'oggetto /user/ . Nella variabile GET action viene memorizzata una stringa che determina l'azione.
Sto usando uno script di riscrittura .htaccess per riscrivere le directory false su questi percorsi interni:
```
RewriteEngine On
RewriteRule ^(.*?)/(.*?)/?$ $1.php?action=$2 [NC,L]
```

Tuttavia, non sono sicuro che questo sia il modo migliore per configurare un'API REST. Ci sarebbero problemi evidenti che mi mancano qui?

In che modo l'albero dei file interno di un'API REST di solito appare o non può essere ragionevolmente detto? Quali sono i pro e i contro dei diversi approcci?

api rest directory-structure

posta Keelan 16.05.2013 - 21:37

fonte

1 risposta

Leggi altre domande sui tag api rest directory-structure

Vale la pena creare una mappa della conoscenza per il software? [chiuso] Pattern degli oggetti di estensione

score 2 · Accepted Answer

Penso che tu sia sulla buona strada ... È difficile dire se un particolare modo di strutturare le cartelle sia "il migliore", ma posso condividere quello che ho visto. In particolare, il modo in cui ASP.NET MVC struttura questo tipo di cose è il seguente:

Modelli
Vista
Controller
{Varie altre cartelle}

Modelli contiene le classi che rappresentano i tuoi modelli di visualizzazione o, nel caso di un progetto API, i tipi di dati che l'API invia e riceve; es. Person {Name, Rank, SerialNumber}.

Viste contiene i file che generano le tue visualizzazioni; per un progetto API non hai realmente viste, dovresti semplicemente usare una sorta di strato di serializzazione JSON o XML, quindi probabilmente non hai bisogno di qualcosa di simile.

Controller contiene le classi su cui sono presenti le tue azioni. Questo è più o meno quello che stai dicendo di fare, ma non vale la separazione tra la classe data (cioè l'oggetto Person, con {Name, Rank, SerialNumber}) e il controller Person, che supporta GET, PUT, POST, DELETE di un oggetto Person.

Varie altre cartelle conterrà qualsiasi altra risorsa di cui hai bisogno; anche non tutto ciò che è necessario per un progetto puramente API.