sails.js
API Blueprint
Ricerca…
Osservazioni
Come funziona l'API di Blueprint?
Quando le vele iniziano a usare le sails lift
, le vele guardano per vedere se hai un controller definito. Nel nostro esempio, abbiamo un controller, il controller utente. Sails fornisce quindi l'accesso alle azioni blueprint per questo controller utente come se fossero state create direttamente nel controller. Anche le vele creano automaticamente percorsi di progetto al momento del sollevamento del server. Quindi, anche se in /config/routes.js
non sono definiti /api/controllers/UserController.js
, e in /api/controllers/UserController.js
non viene definita alcuna azione esplicita, dopo aver /api/controllers/UserController.js
il server tutte queste rotte e azioni sono disponibili per l'uso.
Percorsi Blueprint
Quando si esegue il sails lift
con i modelli abilitati, il framework controlla i controller, i modelli e la configurazione per collegare automaticamente determinati percorsi. Questi percorsi impliciti del modello consentono alla tua app di rispondere a determinate richieste senza che tu debba vincolare manualmente tali percorsi nel tuo file config/routes.js
. Per impostazione predefinita, i percorsi del modello puntano alle corrispondenti azioni del progetto, ognuna delle quali può essere sostituita con un codice personalizzato.
Ci sono tre tipi di rotte blueprint in Sails:
- Percorsi RESTful , dove il percorso è sempre
/:model/:id?
. Quando il modelloUser
e il controller sono definiti, il blueprint associa implicitamente le rotte RESTful nel seguente modo:
Queste rotte utilizzano il verbo HTTP per determinare l'azione da eseguire anche se il percorso è lo stesso. Quindi, una richiesta'GET /user/:id?': { controller: 'User', action: 'find' }, 'POST /user': { controller: 'User', action: 'create' }, 'PUT /user/:id?': { controller: 'User', action: 'update' }, 'DELETE /user/:id?': { controller: 'User', action: 'destroy' }
POST
a/user
creerà un nuovo utente, una richiestaPUT
a/user/123
aggiornerà l'utente con la chiave primaria 123 e una richiestaDELETE
a/user/123
cancellerà l'utente la cui chiave primaria è 123. In un ambiente di produzione, le rotte RESTful dovrebbero generalmente essere protette da policy per evitare accessi non autorizzati.
Percorsi di scelta rapida , in cui l'azione da intraprendere è codificata nel percorso. Per il nostro modello di utente e controller, Sails associa implicitamente quattro percorsi di scelta rapida.
'GET /user/find/:id?': { controller: 'User', action: 'find' }, 'GET /user/create/:id?': { controller: 'User', action: 'create' }, 'GET /user/update/:id?': { controller: 'User', action: 'update' }, 'GET /user/destroy/:id?': { controller: 'User', action: 'destroy' }
Ad esempio, il collegamento
/user/create?name=joe
crea un nuovo utente, mentre/user/update/1?name=mike
aggiorna il campo del nome dell'utente # 1. Nota che questi percorsi rispondono solo alle richiesteGET
. I percorsi di scelta rapida sono molto utili per lo sviluppo, ma in genere dovrebbero essere disabilitati in un ambiente di produzione. Non è progettato per essere utilizzato in produzione.Percorsi di azione , che creano automaticamente percorsi per le azioni del controller personalizzato. Ad esempio, lascia che la
query
sia un'azione personalizzata definita nel controller utente. Quindi seguire le rotte sarebbe implicitamente disponibile per le vele -'GET /user/query/:id?': { controller: 'User', action: 'query' }, 'POST /user/query/:id?': { controller: 'User', action: 'query' }, 'PUT /user/query/:id?': { controller: 'User', action: 'query' }, 'DELETE /user/query/:id?': { controller: 'User', action: 'query' }
Se la richiesta è fatta in
/user/query/:id?
percorso quindi indipendente sul verbo HTTP l'azione sarebbe la stessa. A differenza dei percorsi RESTful e di scelta rapida, i percorsi di azione non richiedono che un controller abbia un file modello corrispondente. Il che significa che se si definisce un controller nel file/api/controllers/FooController.js
ma nessun modello nel file/api/models/Foo.js
, non ci sarebbe nessun RESTful o percorso di scorciatoia con/foo
ma ci saranno comunque percorsi di azione disponibile per l'uso.
Ordine di percorsi corrispondenti
Quando arriva una richiesta, le vele corrisponderanno prima alla rotta contro rotte esplicitamente definite. Se corrisponde, non viene eseguita alcuna ulteriore corrispondenza e viene eseguita l'azione corrispondente. Ma se non corrisponde, la rotta viene confrontata in primo luogo con le rotte di azione del modello, se non corrisponde a quelle di riposo e se non corrisponde a quelle di collegamento. Quindi se il tuo file /config/routes.js
ha qualche voce come la seguente-
'/user/query/:id?': {
controller: 'User',
action: 'find'
}
Quindi non è possibile aspettarsi che i percorsi di azione della query
funzionino. Poiché la stessa route del percorso di azione della query
dovrebbe essere confrontata con le rotte di definizione esplicita e l'azione di find
del controller utente verrà eseguita.
Azioni blueprint
Le azioni Blueprint (da non confondere con i percorsi di azione blueprint) sono azioni generiche progettate per funzionare con qualsiasi controller che ha un modello con lo stesso nome (ad esempio ParrotController
avrebbe bisogno di un modello Parrot
). Pensa a loro come il comportamento predefinito per la tua applicazione. Ad esempio, se hai un modello User.js
e un controller UserController.js
vuoto, find
, create
, update
, destroy
, populate
, add
e remove
azioni implicitamente, senza doverle scrivere.
Per impostazione predefinita, i percorsi RESTful e le rotte di scelta rapida di blueprint sono associati alle rispettive azioni blueprint corrispondenti. Tuttavia, qualsiasi azione di modello può essere sovrascritta per un particolare controller creando un'azione personalizzata in quel file di controller (ad es. ParrotController.find
). In alternativa, puoi sovrascrivere l'azione del modello ovunque nella tua app creando la tua azione personalizzata.
Sails viene fornito con le seguenti azioni blueprint:
- trova
- trova uno
- creare
- aggiornare
- distruggere
- popolare
- Inserisci
- rimuovere
Disabilitare rotte Blueprint
Base globale : la configurazione dell'API Blueprint è definita nel file
/config/blueprint.js
. Da qui puoi abilitare o disabilitare tutti e tre i tipi di rotte blueprint per tutti i controller. Ad esempio, se si desidera disabilitare i percorsi di scelta rapida del modello per tutti i controller, ma si desidera mantenere attive sia le rotte di azione che quelle di riposo, allora il tuo/config/blueprint.js
dovrebbe essere come questo -module.exports.blueprints = { action: true, rest: true, shortcut: false }
In base al controller : è inoltre possibile sovrascrivere qualsiasi impostazione da
/config/blueprints.js
in base al controller definendo una chiave "_config" nella definizione del controller e assegnandole un oggetto di configurazione con le sostituzioni per le impostazioni in questo file. Ad esempio, se si desidera avere percorsi di scelta rapida abilitati solo per il controller utente ma non per altri controller, con la configurazione del modello di cui sopra è necessario avere la seguente coppia di valori chiave nel controller utente.module.exports = { _config: { actions: true, shortcuts: true, rest: true } }