Providing the version information through the Accept (request) header along with the content-type (media) in response is the preferred way as this helps to version APIs without any impact on the URI. As we've already learned about content-negotiation, in Chapter 2, Design Strategy, Guidelines, and Best Practices, let's jump to a code implementation of versioning through Accept and Content-Type:

@GetMapping(value = "/investorsbyacceptheader",
headers = "Accept=application/investors-v1+json,
application/investors-v1.1+json")
public List<Investor> fetchAllInvestorsForGiven..()
throws VersionNotSupportedException {
return getResultsAccordingToVersion("1.1");
}

The following screenshot is the output of the preceding code:

The preceding screenshot of the postman tool depicts the execution of our investor service app versioning through the Accept header. Please observe the response header content-type as well.

As we have seen, each type of versioning methodology has advantages and disadvantages, so we need to determine the right approach on a case-by-case basis. However, the content-negotiation and custom headers are a proponent of RESTful-compliant services. We will move on to one of the essential pattern authentication and authorization.