Как вы обрабатываете версию api в приложении Node/Express

Ответ 1

Прежде всего, если вы создаете REST API и только что начали, вы можете захотеть использовать Restify вместо Express. Хотя Express, безусловно, может быть использован для этой цели, Restify был разработан со всеми требованиями к серверу REST API: стандартизованные исключения, управление версиями API и т.д.

Таким образом, я сказал, что ваша первая проблема - это недостаток дизайна. Вы должны создавать отдельные конечные точки только тогда, когда новые API не будут обратно совместимы с предыдущей версией, то есть когда увеличена основная версия (например, с v1 по v2). Это должно происходить как можно реже!
Если вы только добавляете новые функции или делаете другие настройки, которые не нарушают существующий код, вам не следует создавать другую конечную точку. Таким образом, вы не должны создавать конечные точки для v1.1, v1.2 и т.д., При условии, что весь код, который работает с v1.0, также будет работать с v1.1 (если это не так, то вы вводите изменения, которые не обратная совместимость, и поэтому вы должны рассмотреть возможность изменения версии на v2).
Обратите внимание, что каждый раз, когда вы вводите обратно-несовместимые изменения, все ваши пользователи должны будут обновить свой код, и вам придется поддерживать старые API-интерфейсы в течение определенного периода времени, достаточного для обновления всех ваших пользователей. Это дорогостоящий процесс, для вас (вам нужно поддерживать старые кодовые базы) и ваших пользователей (они должны обновить свой код), и поэтому это должно происходить как можно реже. Кроме того, для каждой версии вам нужно написать документацию, создать примеры и т.д.
(В нижней части: потратьте много времени на разработку своего сервера API, чтобы он, скорее всего, оставался без перекос-несовместимых изменений как можно дольше)

Чтобы ответить на ваш вопрос, тогда способ сделать это мог бы создать подпапки для каждого набора API (каждая версия), а затем установить маршрутизатор соответственно. Например, ваш проект будет выглядеть так:

/
-- app.js
-- routes/
-- -- v1/
-- -- -- auth.js
-- -- -- list.js
-- -- v2/
-- -- -- auth.js
-- -- -- list.js

Это не должно быть проблемой: поскольку v2 не поддерживает обратную совместимость с v1, скорее всего, эти два файла довольно разные.
Затем в Express просто используйте маршрутизатор соответственно. Например:

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)

Существуют и другие варианты. Например, более элегантным (хотя и немного продвинутым) решением может быть: http://j-query.blogspot.ca/2013/01/versioned-apis-with-express.html

Примечание по этому методу

В то время как в соответствии с семестром каждое отставание, несовместимое с изменением, должно увидеть увеличение основной версии API, если вы планируете внедрить множество существенных различий между v1 и v2 (с очень небольшой возможностью повторного использования кода), то этот подход не для вас.

В этом последнем случае вы можете создать два отдельных приложения Node.js для v1 и v2, а затем настроить правильную маршрутизацию с помощью nginx. Версии не будут выполняться на уровне приложения (каждое приложение будет отвечать на '/auth', '/list/: id' и NOT '/v1/auth', '/v1/list: id' и т.д.), Но nginx пересылает запросы с префиксом '/v1/' на один рабочий сервер и с префиксом '/v2/' другому.

Ответ 2

Рамки, такие как restify, лучше подходят для управления версиями api, но если вы используете экспресс и вам нужен легкий модуль для версии ваших маршрутов, попробуйте этот модуль npm https://www.npmjs.com/package/express-routes-versioning

позволяет индивидуально управлять отдельными маршрутами. Он поддерживает базовое управление версиями semver на сервере для соответствия нескольким версиям. (если нужно). Он агностик относительно конкретных стратегий управления версиями и позволяет приложению устанавливать версию.

Пример кода

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

Ответ 3

Я предполагаю, что ваш API нарушает ограничения REST, по крайней мере, ограничение без ограничений. Проверьте равномерное ограничение интерфейса REST. В нем рассказывается, как отделить клиентов от реализации API. После того, как вы это сделали, вам, вероятно, больше не понадобится версия.

Если вы не хотите применять ограничения REST, я думаю, что URL-адрес должен содержать только основной номер версии (чтобы указать изменения, не поддерживающие обратную совместимость). После этого вы можете определить специфичные для поставщика типы MIME или параметры типа контента, в которых вы можете описать незначительные, просмотреть и построить номера версий, если хотите. Таким образом, ваши клиенты должны отправлять заголовки принимающего и контентного типов с этими параметрами версии.

Как раз упомянуть, если вы хотите поддерживать сразу несколько версий, вам нужно написать документацию для каждого из них.