web-dev-qa-db-fra.com

Différence entre app.use et app.get dans express.js

Je suis un peu nouveau pour exprimer et node.js, et je ne peux pas comprendre la différence entre app.use et app.get. Il semble que vous puissiez utiliser les deux pour envoyer des informations. Par exemple:

app.use('/',function(req, res,next) {
    res.send('Hello');
    next();
});

semble être le même que celui-ci:

app.get('/', function (req,res) {
   res.send('Hello');
});
node.jsexpress
178
Andre Vorobyov

app.use() permet de lier middleware à votre application. path est un chemin " de montage " ou "" et limite le middleware à s’appliquer uniquement aux chemins demandés par commence par elle. Il peut même être utilisé pour intégrer une autre application:

// subapp.js
var express = require('express');
var app = modules.exports = express();
// ...

// server.js
var express = require('express');
var app = express();

app.use('/subapp', require('./subapp'));

// ...

En spécifiant / en tant que chemin " mount ", app.use() répondra à tout chemin commençant par /, qui sont tous identiques et indépendamment de HTTP. verbe utilisé:

  • GET /
  • PUT /foo
  • POST /foo/bar
  • etc.

app.get() , d’autre part, fait partie d’Express ' application routing et est destiné à la correspondance et au traitement d’un itinéraire spécifique à la demande du verbe HTTP GET:

  • GET /

Et le routage équivalent pour votre exemple de app.use() serait en réalité:

app.all(/^\/.*/, function (req, res) {
    res.send('Hello');
});

( Update: Tentative de mieux démontrer les différences. )

Les méthodes de routage, y compris app.get(), sont des méthodes pratiques qui vous aident à aligner les réponses aux demandes avec plus de précision. Ils ajoutent également un support pour des fonctionnalités telles que parameters et next('route').

Dans chaque app.get() se trouve un appel à app.use(); vous pouvez donc certainement faire tout cela avec app.use() directement. Mais cela nécessitera souvent (probablement inutilement) de réimplémenter diverses quantités de code passe-partout.

Exemples:

  • Pour les routes simples et statiques:

    app.get('/', function (req, res) {
  // ...
});

    vs.

    app.use('/', function (req, res, next) {
  if (req.method !== 'GET' || req.url !== '/')
    return next();

  // ...
});

  • Avec plusieurs gestionnaires pour le même itinéraire:

    app.get('/', authorize('ADMIN'), function (req, res) {
  // ...
});

    vs.

    const authorizeAdmin = authorize('ADMIN');

app.use('/', function (req, res, next) {
  if (req.method !== 'GET' || req.url !== '/')
    return next();

  authorizeAdmin(req, res, function (err) {
    if (err) return next(err);

    // ...
  });
});

  • Avec paramètres:

    app.get('/item/:id', function (req, res) {
  let id = req.params.id;
  // ...
});

    vs.

    const pathToRegExp = require('path-to-regexp');

function prepareParams(matches, pathKeys, previousParams) {
  var params = previousParams || {};

  // TODO: support repeating keys...
  matches.slice(1).forEach(function (segment, index) {
    let { name } = pathKeys[index];
    params[name] = segment;
  });

  return params;
}

const itemIdKeys = [];
const itemIdPattern = pathToRegExp('/item/:id', itemIdKeys);

app.use('/', function (req, res, next) {
  if (req.method !== 'GET') return next();

  var urlMatch = itemIdPattern.exec(req.url);
  if (!urlMatch) return next();

  if (itemIdKeys && itemIdKeys.length)
    req.params = prepareParams(urlMatch, itemIdKeys, req.params);

  let id = req.params.id;
  // ...
});

Remarque: L'implémentation Express de ces fonctionnalités est décrite dans les Router, Layer ET Route .

187
Jonathan Lonowski

app.use est la méthode "de niveau inférieur" de Connect, le framework middleware dont dépend Express.

Voici ma ligne directrice:

  • Utilisez app.get si vous souhaitez exposer une méthode GET.
  • Utilisez app.use si vous souhaitez ajouter un middleware (un gestionnaire de la requête HTTP avant qu'elle n'arrive sur les routes que vous avez configurées dans Express), ou si vous souhaitez rendre vos routes modulaires (par exemple, exposer un ensemble de routes à partir d’un module npm que d’autres applications Web pourraient utiliser).
44
Matthew Ratzloff

Tout simplement app.use signifie "Exécuter ceci sur TOUTES les demandes"
app.get signifie “Exécuter ceci sur une requête GET, pour l'URL donnée”

40
Dhyan Mohandas

app.get est appelé lorsque méthode HTTP est défini sur GET, alors que app.use est appelé quelle que soit la méthode HTTP et définit donc une couche située en haut. de tous les autres types RESTful auxquels les packages express vous donnent accès.

26
MrLore

Différence entre app.use & app.get:

app.use → Il est généralement utilisé pour introduire des middlewares dans votre application et peut gérer tout type de requêtes HTTP.

app.get → C'est uniquement pour gérer les requêtes HTTP GET.

Maintenant, il y a une confusion entre app.use & app.all. Sans aucun doute, il y a une chose commune en eux, que les deux peuvent gérer tout type de demandes HTTP. Mais il y a quelques différences qui nous recommandent d'utiliser app.use pour les middlewares et app.all pour la gestion des tournées.

  1. app.use() → Un seul rappel est nécessaire.
    app.all() → Plusieurs rappels peuvent être nécessaires.

  2. app.use() ne verra que si l'URL commence par le chemin spécifié.
    Mais, app.all() correspondra au chemin complet.

Par exemple,

app.use( "/book" , middleware);
// will match /book
// will match /book/author
// will match /book/subject

app.all( "/book" , handler);
// will match /book
// won't match /book/author   
// won't match /book/subject    

app.all( "/book/*" , handler);
// won't match /book        
// will match /book/author
// will match /book/author
  1. next() appel à l'intérieur de app.use() appellera le prochain logiciel intermédiaire ou n'importe quel gestionnaire d'itinéraire, mais next() appel à l'intérieur de app.all() invoquera le prochain gestionnaire d'itinéraire (app.all(), app.get/post/put... etc.) uniquement. S'il y a un middleware après, il sera ignoré. Il est donc conseillé de placer tous les middlewares toujours au-dessus des gestionnaires d’itinéraires.
12
Ankit Kumar