sails.js
Blueprint API

Remarques

Itinéraires Blueprint

Lorsque vous exécutez sails lift avec les blueprints activés, la structure inspecte vos contrôleurs, modèles et configurations afin de lier automatiquement certains itinéraires. Ces itinéraires bleus implicites permettent à votre application de répondre à certaines demandes sans que vous ayez à les lier manuellement dans votre fichier config/routes.js . Par défaut, les itinéraires des plans directeurs pointent vers les actions correspondantes du plan directeur, chacune pouvant être remplacée par du code personnalisé.

Il existe trois types d’itinéraires de plan dans Sails:

• RESTful routes , où le chemin est toujours /:model/:id? . Lorsque le modèle User et le contrôleur sont définis, blueprint lie implicitement les routes RESTful de la manière suivante:

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

  Ces itinéraires utilisent le verbe HTTP pour déterminer l'action à entreprendre même si l'itinéraire est identique. Ainsi, une requête POST à /user créera un nouvel utilisateur, une requête PUT à /user/123 mettra à jour l'utilisateur avec la clé primaire 123 et une requête DELETE à /user/123 supprimera l'utilisateur dont la clé primaire est 123. In Dans un environnement de production, les routes RESTful doivent généralement être protégées par des règles pour éviter les accès non autorisés.

• Itinéraires de raccourci , où l'action à prendre est codée dans le chemin. Pour notre modèle d'utilisateur et notre contrôleur, Sails se lie implicitement aux quatre routes de raccourci suivantes.

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

  Par exemple, le raccourci /user/create?name=joe crée un nouvel utilisateur, tandis que /user/update/1?name=mike met à jour le champ de nom de l'utilisateur # 1. Notez que ces itinéraires ne répondent qu'aux requêtes GET . Les raccourcis sont très pratiques pour le développement, mais devraient généralement être désactivés dans un environnement de production. Il n'est pas conçu pour être utilisé en production.

• Itinéraires d'action , qui créent automatiquement des itinéraires pour vos actions de contrôleur personnalisées. Par exemple, laissez query être une action personnalisée définie dans le contrôleur utilisateur. Ensuite, les routes suivantes seraient implicitement disponibles pour les voiles -

  '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 demande est faite dans /user/query/:id? route alors indépendante sur le verbe HTTP, l'action serait la même. Contrairement aux itinéraires RESTful et aux raccourcis, les itinéraires d'action ne nécessitent pas qu'un contrôleur dispose d'un fichier de modèle correspondant. Ce qui signifie que si vous définissez un contrôleur dans le fichier /api/controllers/FooController.js mais pas de modèle dans le fichier /api/models/Foo.js , il n'y aurait pas de route RESTful ou de raccourci avec /foo mais il y aura toujours des routes d'action disponible à l'emploi.

Ordre des itinéraires correspondant

Lorsqu'une demande arrive, les voiles vont d'abord correspondre à l'itinéraire par rapport à des itinéraires explicitement définis. Si elle correspond, aucune autre correspondance n'est effectuée et l'action correspondante est exécutée. Mais si elle ne correspond pas, la route est comparée en premier lieu aux routes d'action du plan, si elle ne correspond pas aux routes de repos et si elle ne correspond pas aux routes de raccourci. Donc, si votre fichier /config/routes.js a une entrée comme la suivante-

  '/user/query/:id?': {
    controller: 'User',
    action: 'find'
  }

Ensuite, vous ne pouvez pas vous attendre à ce que query routes d'action de query fonctionnent. Étant donné que le même itinéraire que l'itinéraire d'action de query serait mis en correspondance avec les routes à définition explicite et find action du contrôleur d'utilisateur serait exécutée.

Actions Blueprint

Les actions Blueprint (à ne pas confondre avec les routes d' action Blueprint) sont des actions génériques conçues pour fonctionner avec n'importe lequel de vos contrôleurs ayant un modèle du même nom (par exemple, ParrotController nécessiterait un modèle Parrot ). Considérez-les comme le comportement par défaut de votre application. Par exemple, si vous avez un modèle User.js et un contrôleur UserController.js vide, find , create , update , destroy , populate , add et remove actions implicitement, sans que vous ayez à les écrire.

Par défaut, les itinéraires et les raccourcis RESTful du plan directeur sont liés à leurs actions correspondantes. Cependant, toute action de plan directeur peut être remplacée pour un contrôleur particulier en créant une action personnalisée dans ce fichier de contrôleur (par exemple, ParrotController.find ). Vous pouvez également remplacer l'action de plan directeur partout dans votre application en créant votre propre action de plan directeur personnalisée.

Sails est livré avec les actions suivantes:

• trouver
• trouverOne
• créer
• mettre à jour
• détruire
• peupler
• ajouter
• retirer

Désactivation des itinéraires du plan directeur

• Base globale : La configuration de l'API Blueprint est définie dans le fichier /config/blueprint.js . Vous pouvez activer ou désactiver les trois types d'itinéraires de plan directeur pour tous les contrôleurs à partir de là. Par exemple, si vous souhaitez désactiver les itinéraires de raccourcis blueprint pour tous vos contrôleurs, mais que vous souhaitez conserver les routes d'action et de repos activées, alors votre /config/blueprint.js devrait être comme ça -

  module.exports.blueprints = {
    action: true,
    rest: true,
    shortcut: false
  }
  

• Par contrôleur : vous pouvez également remplacer les paramètres de /config/blueprints.js par contrôleur en définissant une clé '_config' dans la définition de votre contrôleur et en lui affectant un objet de configuration avec les paramètres de remplacement. dans ce fichier Par exemple, si vous souhaitez que les raccourcis soient uniquement activés pour votre contrôleur utilisateur, mais pas pour d'autres contrôleurs, vous devez disposer de la paire de valeurs clé suivante dans le contrôleur utilisateur avec la configuration de plan ci-dessus.

  module.exports = {
    _config: {
      actions: true,
      shortcuts: true,
      rest: true
    }
  }