sails.js
Blueprint API
Buscar..
Observaciones
¿Cómo funciona la API de Blueprint?
Cuando las velas inicialmente comienzan a usar el sails lift
, ve las velas para ver si tiene algún controlador definido. En nuestro ejemplo, tenemos un controlador, el controlador de Usuario. Sails luego proporciona acceso a las acciones de planos para este controlador de usuario como si las hubiéramos construido nosotros mismos en el controlador. Sails también crea automáticamente rutas de planos en el momento de levantar el servidor. Entonces, incluso si no hay rutas definidas en /config/routes.js
y ninguna acción está definida en /api/controllers/UserController.js
explícitamente, después de levantar el servidor, todas estas rutas y acciones están disponibles para su uso.
Rutas del plano
Cuando se ejecuta el sails lift
con los planos habilitados, el marco inspecciona sus controladores, modelos y configuración para enlazar ciertas rutas automáticamente. Estas rutas de planos implícitas permiten que su aplicación responda a ciertas solicitudes sin que tenga que vincularlas manualmente en su archivo config/routes.js
. De forma predeterminada, las rutas de planos apuntan a sus correspondientes acciones de planos, cualquiera de las cuales puede ser anulada con un código personalizado.
Hay tres tipos de rutas de planos en Sails:
- Rutas REST completas , donde la ruta es siempre
/:model/:id?
. Cuando se define el modelo deUser
y el controlador, blueprint vincula las rutas RESTful implícitamente de la siguiente manera:
Estas rutas utilizan el verbo HTTP para determinar la acción a realizar, incluso si la ruta es la misma. Por lo tanto, una solicitud'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
para/user
creará un nuevo usuario, una solicitudPUT
para/user/123
actualizará al usuario con la clave principal 123 y una solicitudDELETE
para/user/123
eliminará al usuario cuya clave principal es 123. En En un entorno de producción, las rutas REST en general deben estar protegidas por políticas para evitar el acceso no autorizado.
Rutas de acceso directo , donde la acción a realizar se codifica en la ruta. Para nuestro modelo de usuario y controlador, Sails se enlaza siguiendo implícitamente cuatro rutas de acceso directo.
'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' }
Como ejemplo, el acceso directo
/user/create?name=joe
crea un nuevo usuario, mientras que/user/update/1?name=mike
actualiza el campo de nombre del usuario # 1. Tenga en cuenta que estas rutas solo responden a las solicitudesGET
. Las rutas de acceso directo son muy útiles para el desarrollo, pero generalmente se deben deshabilitar en un entorno de producción. No está diseñado para ser utilizado en la producción.Rutas de acción , que crean automáticamente rutas para las acciones de su controlador personalizado. Por ejemplo, deje que la
query
sea una acción personalizada definida en el controlador de usuario. Entonces, las siguientes rutas estarían implícitamente disponibles para las velas:'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' }
Si la solicitud se realiza en
/user/query/:id?
ruta entonces independiente en el verbo HTTP la acción sería igual. A diferencia de las rutas de acceso directo y REST, las rutas de acción no requieren que un controlador tenga un archivo de modelo correspondiente. Lo que significa que si define un controlador en el archivo/api/controllers/FooController.js
pero no hay un modelo en el archivo/api/models/Foo.js
, no habrá una ruta de acceso directo o RESTful con/foo
pero aún habrá rutas de acción disponible para usar.
Orden de rutas coincidentes
Cuando llega una solicitud, las velas primero harán coincidir la ruta con las rutas explícitamente definidas. Si coincide, no se realiza ninguna otra coincidencia y se ejecuta la acción correspondiente. Pero si no coincide, entonces la ruta se compara primero con las rutas de acción de planos, si no coincide luego con las rutas de descanso y si tampoco coincide con las rutas de acceso directo. Entonces, si su archivo /config/routes.js
tiene alguna entrada como la siguiente:
'/user/query/:id?': {
controller: 'User',
action: 'find'
}
Entonces no puedes esperar que las rutas de acción de query
funcionen. Debido a que la misma ruta que la ruta de acción de query
se compararía con las rutas explícitamente definidas y la acción de find
del controlador de usuario se ejecutaría.
Acciones de Blueprint
Las acciones de planos (que no deben confundirse con las rutas de acciones de planos) son acciones genéricas diseñadas para funcionar con cualquiera de sus controladores que tengan un modelo del mismo nombre (por ejemplo, ParrotController
necesitaría un modelo de Parrot
). Piense en ellos como el comportamiento predeterminado para su aplicación. Por ejemplo, si tiene un modelo User.js
y un controlador UserController.js
vacío, las acciones de find
, create
, update
, destroy
, populate
, add
y remove
existen de manera implícita, sin que tenga que escribirlas.
De forma predeterminada, las rutas RESTful y las rutas de acceso directo de blueprint están vinculadas a sus acciones de blueprint correspondientes. Sin embargo, cualquier acción de blueprint puede ser anulada para un controlador en particular al crear una acción personalizada en ese archivo de controlador (por ejemplo, ParrotController.find
). Alternativamente, puede anular la acción de planos en cualquier parte de su aplicación creando su propia acción de planos personalizada.
Sails se envía con las siguientes acciones de planos:
- encontrar
- Encuentra uno
- crear
- actualizar
- destruir
- poblar
- añadir
- retirar
Deshabilitar rutas de planos
Base global : la configuración de la API de Blueprint se define en el archivo
/config/blueprint.js
. Puede habilitar o deshabilitar los tres tipos de rutas de planos para todos los controladores desde allí. Como ejemplo, si desea deshabilitar las rutas de acceso directo de blueprint para todos sus controladores pero desea mantener activadas las rutas de acción y de descanso, entonces/config/blueprint.js
debería ser así:module.exports.blueprints = { action: true, rest: true, shortcut: false }
En base a controlador : también puede anular cualquiera de las configuraciones de
/config/blueprints.js
en base a controlador definiendo una clave '_config' en la definición de su controlador, y asignándole un objeto de configuración con reemplazos para las configuraciones en este archivo. Como ejemplo, si desea que las rutas de acceso directo estén habilitadas solo para su controlador de usuario pero no para más controladores, con la configuración de plan anterior debe tener el siguiente par de valores clave en el controlador de usuario.module.exports = { _config: { actions: true, shortcuts: true, rest: true } }