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 de User y el controlador, blueprint vincula las rutas RESTful implícitamente de la siguiente manera:
    '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'
    }
    
    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 POST para /user creará un nuevo usuario, una solicitud PUT para /user/123 actualizará al usuario con la clave principal 123 y una solicitud DELETE 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 solicitudes GET . 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
      }
    }
    
    


Modified text is an extract of the original Stack Overflow Documentation
Licenciado bajo CC BY-SA 3.0
No afiliado a Stack Overflow