A simple test of restify versioning.

server.js

/* jshint node:true */
'use strict';

var restify = require("restify"),
server = restify.createServer({ version: '1.0.0' });

server.pre(function (req, res, next) {
    console.log('VERSION HEADER: %s', req.headers['accept-version']);
    console.log('VERSION VIA RESTIFY: %s', req.version());

    if (!req.headers['accept-version']) {
      console.log('----> no version sent...updating to 1.0.0');
      req._version = '1.0.0';
    }

    return next();
});

var PATH1 = "/hello/:name";
var PATH2 = "/goodbye/:name";

server.get(PATH1, function(req,res,next) {
    console.log('v0.0.0');
    res.json(201, { hello: 'v0.0.0' });

    return next();
});

server.get({ path: PATH1, version: ['1.8.0'] }, function(req,res,next) {
    console.log('v1.8.0');
    res.json(201, { hello: 'v1.8.0' });

    return next();
});

/**
 * ********** PATH 2 **********
 */

server.get(PATH2, function(req,res,next) {
    console.log('v0.0.0');
    res.json(201, { hello: 'v0.0.0' });

    return next();
});

server.listen(8989);

/**
 * REQUEST OUTPUT
 */
 
$ curl -is localhost:8989/hello/me
HTTP/1.1 201 Created
Content-Type: application/json
Content-Length: 18
Date: Mon, 11 May 2015 18:03:03 GMT
Connection: keep-alive

{"hello":"v0.0.0"}

$ curl -is localhost:8989/goodbye/me
HTTP/1.1 201 Created
Content-Type: application/json
Content-Length: 18
Date: Mon, 11 May 2015 18:05:41 GMT
Connection: keep-alive

{"hello":"v0.0.0"}

$ curl -is localhost:8989/hello/me -H 'accept-version: 1.8.0'
HTTP/1.1 201 Created
Content-Type: application/json
Content-Length: 18
Date: Mon, 11 May 2015 18:08:36 GMT
Connection: keep-alive

{"hello":"v1.8.0"}

$ curl -is localhost:8989/goodbye/me -H 'accept-version: 1.8.0'
HTTP/1.1 400 Bad Request
Content-Type: application/json
Content-Length: 79
Date: Mon, 11 May 2015 18:09:20 GMT
Connection: keep-alive

{"code":"InvalidVersion","message":"1.8.0 is not supported by GET /goodbye/me"}

Following scenarios are what we need:

1. A build does not send an Accept-Version header at all (all old builds currently in the App Store)
   • These old builds need to support autosuggest v1
2. A build sends Accept-Version header (this will start with build 1.8.0 and each new iOS version will send Accept-Version with the latest version number)
   • Builds 1.8.x and higher need to support autosuggest v2

We had also discussed a way to fallback to the latest available route e.g. if the app sends Accept-Version higher than what's currently supported it should use the latest available... this requirement is optional and as discussed we might even be better with having to update it manually to require additional oversight for each new version.
An example of the above scenario would be:

• Latest route is 1.8.0
• New app version 1.9.0 sends an Accept-Version of 1.9.0 - error occurs (as we discussed over the phone, this is OK)

How we handle the last case is up to you

Quick, empirical notes:

• If no Accept-Version is sent, Restify always defaults to the latest version of a route if/when there is a mix of versioned and unversioned for the same route.
• I can write middleware to catch a non-existent Accept-Version and set the version to 1.0.0 which will send a mixed (versioned/unversioned) route to the unversioned option.
• If a route is unversioned only (e.g. server.get('/foo/bar', handler)) the default version doesn't fallback to the unversioned route, but throws a 400 instead. I'm not sure I understand that, but this is what my eyes tell me.

What I can't seem to find is any way to do anything we want with an Accept-Version header value of 1.9.0.