node.js - principiantes - ¿Cómo manejas la versión api en una aplicación Node/Express?
node js tutorial (3)
Soy bastante nuevo en Node.js y me enfrento al siguiente problema.
Mi middleware comenzó con el enlace api/v1/login y un grupo de puntos finales. Luego api/v1.1 introdujo 2 puntos finales más. api/v1.2 ahora es el último y tiene algunos puntos finales nuevos.
¿Cómo debo manejar esta versión de API de una manera eficiente? ¿Cómo se hacen los puntos finales de una versión disponible para las próximas versiones también?
En primer lugar, si está creando una API REST y acaba de comenzar, puede considerar usar Restify lugar de Express. Si bien Express puede ser utilizado para este propósito, Restify ha sido diseñado con todos los requisitos para un servidor REST API: excepciones estandarizadas, control de versiones de API, etc.
Dicho esto, creo que su primer problema es un defecto de diseño. Debe crear puntos finales separados solo cuando las nuevas API no son compatibles con versiones anteriores, es decir, cuando se aumenta la versión principal (por ejemplo, de v1 a v2). ¡Esto debería suceder con la menor frecuencia posible!
Si solo está agregando nuevas funciones o haciendo otros ajustes que no rompan el código existente, entonces no debe crear un punto final diferente. Por lo tanto, no debe crear puntos finales para v1.1, v1.2, etc., siempre que todo el código que funciona con v1.0 también funcione con v1.1 (si ese no es el caso, entonces está introduciendo cambios que no son compatibles con versiones anteriores, por lo que debería considerar cambiar la versión a v2).
Tenga en cuenta que cada vez que introduzca cambios incompatibles con versiones anteriores, todos sus usuarios deberán actualizar su código, y tendrá que admitir las API antiguas durante un período de tiempo suficiente para que todos los usuarios se actualicen. Este es un proceso costoso, para usted (necesita mantener bases de código antiguas) y también para sus usuarios (necesitan actualizar su código) y, por lo tanto, debería ocurrir con la menor frecuencia posible. Además, para cada versión necesita escribir documentación, crear ejemplos, etc.
(Conclusión: dedique mucho tiempo a diseñar su servidor de API, por lo que es probable que dure sin cambios incompatibles con la versión anterior)
Para responder a su pregunta, entonces, una forma de hacerlo podría ser crear subcarpetas para cada conjunto de API (cada versión), y luego configurar el enrutador en consecuencia. Por ejemplo, su proyecto se verá como:
/
-- app.js
-- routes/
-- -- v1/
-- -- -- auth.js
-- -- -- list.js
-- -- v2/
-- -- -- auth.js
-- -- -- list.js
Eso no debería ser un problema: dado que v2 no es compatible con versiones anteriores de v1, es probable que los dos archivos sean muy diferentes.
Luego, en Express solo use el enrutador como corresponda. Por ejemplo:
app.get(''/v1/list/:id'', v1.list)
app.all(''/v1/auth'', v1.auth)
app.get(''/v2/list/:id'', v2.list)
app.all(''/v2/auth'', v2.auth)
Hay otras opciones, sin embargo. Por ejemplo, una solución más elegante (aunque ligeramente avanzada) puede ser: http://j-query.blogspot.ca/2013/01/versioned-apis-with-express.html
Nota sobre este método
Si bien, según semver, cada cambio incompatible con versiones anteriores debería ver un aumento en la versión principal de las API, si planea implementar muchas y sustanciales diferencias entre v1 y v2 (con muy pocas posibilidades de reutilizar el código), entonces esto El enfoque no es para ti.
En este último caso, es posible que desee crear dos aplicaciones Node.js separadas para v1 y v2, y luego configurar el enrutamiento adecuado utilizando nginx. La versión no se realizará a nivel de aplicación (cada aplicación responderá a ''/ auth'', ''/ list /: id'' y NO ''/ v1 / auth'', ''/ v1 / list: id'', etc.), pero nginx reenviará las solicitudes con el prefijo ''/ v1 /'' a un servidor de trabajo, y las que tengan el prefijo ''/ v2 /'' al otro.
Los marcos como restify son más adecuados para las versiones de API, pero si está utilizando Express y necesita un módulo ligero para la versión de sus rutas, pruebe este módulo npm https://www.npmjs.com/package/express-routes-versioning
El módulo permite que las rutas individuales sean versionadas por separado. Es compatible con las versiones básicas de semver en el servidor para que coincida con varias versiones. (si es necesario). Es independiente de las estrategias de versionamiento específicas y permite que la aplicación establezca la versión.
Código de muestra
var app = require(''express'')();
var versionRoutes = require(''express-routes-versioning'')();
app.listen(3000);
app.use(function(req, res, next) {
//req.version is used to determine the version
req.version = req.headers[''accept-version''];
next();
});
app.get(''/users'', versionRoutes({
"1.0.0": respondV1,
"~2.2.1": respondV2
}));
// curl -s -H ''accept-version: 1.0.0'' localhost:3000/users
// version 1.0.0 or 1.0 or 1 !
function respondV1(req, res, next) {
res.status(200).send(''ok v1'');
}
//curl -s -H ''accept-version: 2.2.0'' localhost:3000/users
//Anything from 2.2.0 to 2.2.9
function respondV2(req, res, next) {
res.status(200).send(''ok v2'');
}
Supongo que su API viola las restricciones REST, al menos ciertamente la restricción sin estado. Compruebe la restricción de interfaz uniforme de REST. Le indica cómo desacoplar a los clientes de la implementación de la API. Después de que hiciste eso probablemente ya no necesitarás versionado.
Si no desea aplicar restricciones REST, creo que la URL debe contener solo el número de versión principal (para indicar cambios no compatibles con versiones anteriores). Después de eso, puede definir los tipos MIME específicos del proveedor o los parámetros de tipo de contenido en los que puede describir el menor, revisar y crear números de versión si lo desea. Por lo tanto, sus clientes deben enviar encabezados de aceptación y tipo de contenido con estos parámetros de versión.
Solo para mencionar, si desea admitir varias versiones a la vez, debe escribir documentación para cada una de ellas.