Though there have been many detractors, I still think URL based versioning is the best way to go. How do you version a header on a resource that goes away or pops into existence? What if I just ask for "application/json" or the "freshest" due to ignorance and you move the target and get even fresher? There is very little practical benefit to versioning in a HTTP header except some argument about URI purity.
https://api.test.com/v1/resource -- standardized API response
https://test.com/resource -- "pure" object if JSON is requested, pretty HTML-wrapped version if not.
You can rely on the versioned API to have a specific format and metadata (things like number of results, query times, etc), while the "pure" version is just a raw JSON object.
I acknowledge that it's a little more work than just banging out a versioned URI, but it's not that much work and I like the URI/conceptual purity.
This sums up pretty much the whole debate. Pragmatics vs idealists.
If the header isn't provided, then the most current version of the API is called. The nice thing about this is that it doesn't 'pollute' the URI and it allows for automatic upgrading to the latest version of the API if the developer doesn't specify the API version.
The web is a great example of this (although you may have to squint a bit to see it). Browsers don't need to add additional code or install plugins to handle forms with different fields or links to content of different types, because the semantics of those elements and their interactions are well-defined.