Sometimes, we have to keep many different versions of a RESTful Web Service alive at the same time. For example, we might need to have version 1 and version 2 of our RESTful Web Service accepting and processing requests. There are many versioning schemes that make it possible to serve many versions of a web service.

The Django REST framework provides five classes in the rest_framework.versioning module. All of them are subclasses of the BaseVersioning class. The five classes allow us to work with a specific versioning scheme.

We can use one of these classes in combination with changes in the URL configurations and other pieces of code to support the selected versioning scheme. Each class is responsible for determining the version based on the implemented schema and to make sure that the specified version number is a valid one based on the allowed version settings. The classes provide different mechanisms to determine the version number. The following are the five versioning classes:

• AcceptHeaderVersioning: This class configures a versioning scheme that requires each request to specify the desired version as an additional value of the media type specified as a value for the Accept key in the header. For example, if a request specifies 'application/json; version=1.2' as the value for the Accept key in the header, the AcceptHeaderVersioning class will set the request.version attribute to '1.2'. This scheme is known as media type versioning, content negotiation versioning or accept header versioning.
• HostNameVersioning: This class configures a versioning scheme that requires each request to specify the desired version as a value included in the hostname in the URL. For example, if a request specifies v2.myrestfulservice.com/drones/ as the URL, it means that the request wants to work with version number 2 of the RESTful Web Service. This scheme is known as hostname versioning or domain versioning.
• URLPathVersioning: This class configures a versioning scheme that requires each request to specify the desired version as a value included in the URL path. For example, if a request specifies v2/myrestfulservice.com/drones/ as the URL, it means that the request wants to work with version number 2 of the RESTful Web Service. The class requires us to work with a version URL keyword argument. This scheme is known as URI versioning or URL path versioning.
• NamespaceVersioning: This class configures the versioning scheme explained for the URLPathVersioning class. The only difference compared with this other class is that the configuration in the Django REST framework application is different. In this case, it is necessary to use URL namespacing.
• QueryParameterVersioning: This class configures a versioning scheme that requires each request to specify the desired version as a query parameter. For example, if a request specifies myrestfulservice.com/?version=1.2, the QueryParameterVersioning class will set the request.version attribute to '1.2'. This scheme is known as query parameter versioning or request parameter versioning.

The previous classes are included in the Django REST framework out of the box. It is also possible to code our own customized versioning scheme. Each versioning scheme has its advantages and trade-offs. In this case, we will work with the NamespaceVersioning class to provide a new version of the RESTful Web Service with a minor change compared to the first version. However, it is necessary to analyze carefully whether you really need to use any versioning scheme. Then, you need to figure out which is the most appropriate one based on your specific needs. Of course, if possible, we should always avoid any versioning scheme because they add complexity to our RESTful Web Service.