sails.js
Blueprint API

Anmärkningar

Blueprint-rutter

När du kör sails lift med ritningar aktiverade, inspekterar ramverket dina styrenheter, modeller och konfiguration för att automatiskt binda vissa rutter. Dessa implicit blueprint-rutter gör att din app kan svara på vissa förfrågningar utan att du behöver binda dessa rutter manuellt i din config/routes.js fil. Som standard pekar planerna för rutt på deras motsvarande planerliga åtgärder , vilka kan åsidosättas med anpassad kod.

Det finns tre typer av planeringsvägar i segel:

• RESTfulla rutter , där vägen alltid är /:model/:id? . När User och controller definieras binder blåkopia RESTful vägar underförstått på följande sätt -

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

  Dessa rutter använder HTTP-verbet för att bestämma vilken åtgärd som ska vidtas även om rutten är densamma. Så en POST begäran till /user skapar en ny användare, en PUT begäran till /user/123 kommer att uppdatera användaren med primärnyckel 123 och en DELETE begäran till /user/123 kommer att radera användaren vars primära nyckel är 123. I i en produktionsmiljö bör RESTful rutter i allmänhet skyddas av policyer för att undvika obehörig åtkomst.

• Genvägsvägar , där åtgärden som ska vidtas kodas i sökvägen. För vår användarmodell och styrenhet binds Sails efter fyra genvägar väsentligt.

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

  Som exempel /user/create?name=joe genvägen en ny användare, medan /user/update/1?name=mike uppdaterar namnfältet för användare # 1. Observera att dessa rutter endast svarar på GET förfrågningar. Genvägsvägar är mycket praktiska för utveckling, men bör i allmänhet vara inaktiverade i en produktionsmiljö. Den är inte utformad för att användas i produktionen.

• Åtgärdsvägar , som automatiskt skapar rutter för dina anpassade kontrolleråtgärder. Låt query vara en anpassad åtgärd som definieras i användarkontrollern. Sedan skulle följande rutter vara implicit tillgängliga för segel -

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

  Om begäran görs i /user/query/:id? rutt sedan oberoende av HTTP-verbet handlingen skulle vara densamma. Till skillnad från RESTful och snabbvägar kräver åtgärdsvägar inte att en kontroller har en motsvarande modellfil. Vilket innebär att om du definierar en controller i /api/controllers/FooController.js men ingen modell i /api/models/Foo.js skulle det inte finnas någon RESTful eller genvägsväg med /foo men det finns fortfarande åtgärdsvägar tillgängliga att använda.

Ordning på matchning av rutter

När en begäran kommer, kommer seglar först att matcha rutten mot uttryckligen definierade rutter. Om det matchar görs ingen ytterligare matchning och motsvarande åtgärd utförs. Men om den inte matchar så matchas rutten först mot handlingsvägar för blåkopia, om den inte matchar sedan mot viltrutter och om den inte matchar någon av dem sedan genvägar. Så om din /config/routes.js har någon post som följande-

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

Då kan du inte förvänta dig att query ska fungera. Eftersom samma rutt som query skulle matchas mot de uttryckligen definierade rutter och find åtgärden från användarkontrollern skulle utföras.

Blueprint-åtgärder

Blueprint-åtgärder (inte att förväxla med blueprint action- rutter ) är generiska åtgärder som är utformade för att arbeta med någon av dina styrenheter som har en modell med samma namn (t.ex. ParrotController skulle behöva en Parrot modell). Tänk på dem som standardbeteendet för din applikation. Om du till exempel har en User.js modell och en tom UserController.js controller kan du find , create , update , destroy , populate , add och remove åtgärder som finns implicit utan att du behöver skriva dem.

Som standard är RESTful-rutorna och genvägsrutorna för blåkopia bundna till deras motsvarande ritningar. Emellertid kan alla planer som en åtgärd kan åsidosättas för en viss styrenhet genom att skapa en anpassad åtgärd i den kontrollfilen (t.ex. ParrotController.find ). Alternativt kan du åsidosätta blueprint-åtgärden överallt i din app genom att skapa din egen anpassade plan.

Seglar fartyg med följande planer:

• hitta
• hitta en
• skapa
• uppdatering
• förstöra
• befolka
• Lägg till
• ta bort

Inaktivera Blueprint-rutter

• Global basis : Blueprint API-konfiguration definieras i /config/blueprint.js . Du kan aktivera eller inaktivera alla tre typer av ritningar för alla kontroller därifrån. Om du till exempel vill inaktivera genvägsrutor för blueprint för alla dina styrenheter men vill hålla både åtgärds- och viltrutter aktiverade, bör /config/blueprint.js vara så här -

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

• På per-controller-basis : Du kan också åsidosätta inställningarna från /config/blueprints.js per-controller-basis genom att definiera en '_config' -nyckel i din controller-defintion och tilldela den ett konfigurationsobjekt med åsidosättningar för inställningarna i den här filen. Som exempel om du vill ha genvägsvägar aktiverade endast för din användarstyrenhet men inte för några fler styrenheter, måste du med ovanstående ritningskonfiguration ha följande nyckelvärdespar i användarstyrenheten.

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