-
Notifications
You must be signed in to change notification settings - Fork 38
Question: Version management when it is at the request header #53
Comments
Middleware that calls a different router depending on the header, each pointing at a different directory? Version as a header, though, doesn't play nice with caching the same way that putting it in a URL does. |
@aidanbon, you could add version-checking middleware which calls // XXX: contrived example
app.use('/api', checkVersion('1.x'), enrouten({ directory: 'api-1.0' }));
app.use('/api', checkVersion('^2.0.0'), enrouten({ directory: 'api-2.0' }));
function checkVersion(routeVersion) {
// XXX: needs: var semver = require('semver');
function SemverHeaderCheck(req, res, next) {
var reqVersion = req.get('X-API-Version');
if (reqVersion && semver.satisfies(reqVersion, routeVersion)) {
next();
}
else {
next('route');
}
}
return SemverHeaderCheck;
} |
Haven't seen any activity here in a while, so I assume @sixlettervariables solution was acceptable or the author found an alternate solution. Thanks @sixlettervariables! |
Thank you @sixlettervariables for the suggestion, and sorry for the delay to follow up. Your suggestion looks good. However, since I'm using Kraken meddleware (https://github.com/krakenjs/meddleware) to register my middlewares, I ended up adding a custom middleware right before the enrouten's "router" middleware. The custom middleware simply inspect the request header for version info (say reqVersion), and then rewrite the request url (i.e. req.url = '/v' + reqVersion + req.originalUrl) to let the downstream enrouten to locate the handler at the appropriate directory. Thanks again for your help! |
I like the enrouten directory option. It organize handlers code intuitively. However, when the API version information is not part of the API path (e.g. in the request header). Any systematic treatment for that?
The text was updated successfully, but these errors were encountered: