django-api-versioning 0.1.2__py3-none-any.whl → 0.1.4__py3-none-any.whl

django_api_versioning/decorators.py

@@ -1,5 +1,6 @@
 from functools import wraps
 from typing import Callable, Optional, List
+from django.views import View
 from .settings import api_settings as settings
 from .registry import registry
 from .exceptions import InvalidVersionError, VersionRangeError, VersionTypeError
@@ -41,8 +42,13 @@ def endpoint(
     """
 
     def decorator(func: Callable) -> Callable:
+        
         @wraps(func)
         def view(*args, **kwargs):
+            # Check if the view is a class-based view (CBV)
+            if isinstance(func, type) and issubclass(func, View):
+                # For class-based views, ensure it's called as a method
+                return func.as_view()(*args, **kwargs)
             return func(*args, **kwargs)
 
         # Read API versioning settings

{django_api_versioning-0.1.2.dist-info → django_api_versioning-0.1.4.dist-info}/METADATA

@@ -1,6 +1,6 @@
 Metadata-Version: 2.1
 Name: django-api-versioning
-Version: 0.1.2
+Version: 0.1.4
 Summary: Django API versioning decorator provides a solution for managing multiple API versions within the Django framework, enabling versioning through URLs with backward compatibility and automatically registering routes.
 Home-page: https://github.com/mojtaba-arvin/django-api-versioning
 Author: Mojtaba Arvin
@@ -118,6 +118,11 @@ def users_view(request):
 
 In this example, the `users_view` function is decorated with the endpoint decorator. This specifies that the view is accessible under version `2` of the API and **supports backward compatibility**. The `backward=True` flag as default ensures that users can also access the previous version (version `1`) at `/api/v1/account_app/users`.
 
+```bash
+api/v1/account_app/users [name='users_list_api']
+api/v2/account_app/users [name='users_list_api']
+```
+
 #### Example for Class-Based Views (CBVs):
 
 For class-based views, you can apply the decorator to methods such as `get`, `post`, or any other HTTP method you need to handle. Here’s an example:
@@ -142,11 +147,13 @@ If you have already installed [Django Rest Framework](https://www.django-rest-fr
 
 ```python
 from rest_framework.views import APIView
+from rest_framework.permissions import AllowAny
 from rest_framework.response import Response
 from django_api_versioning.decorators import endpoint
 
 @endpoint("users", version=2, app_name='account_app', view_name="users_list_api")
 class UsersAPIView(APIView):
+    permission_classes = [AllowAny]
 
     def get(self, request):
         return Response({"message": "API Version 2 Users"})
@@ -154,10 +161,12 @@ class UsersAPIView(APIView):
 
 #### URL Generation Based on Versioning:
 
-Once the decorator is applied, the URLs for your API will be generated based on the version specified in the decorator. For example, if the `API_MIN_VERSION` in your settings.py is set to `1` and the version in the decorator is set to `2`, the following URLs will be available:
+Once the decorator is applied, the URLs for your API will be generated based on the version specified in the decorator. For example, if the `API_MIN_VERSION` in your `settings.py` is set to `1` and the version in the decorator is set to `2`, the following URLs will be available:
 
-- `/api/v1/account_app/users`
-- `/api/v2/account_app/users`
+```bash
+api/v1/account_app/users [name='users_list_api']
+api/v2/account_app/users [name='users_list_api']
+```
 
 The `API_MIN_VERSION` setting ensures that users can access the API using different versions, providing backward compatibility. You can adjust which versions are considered valid by modifying the `API_MIN_VERSION` and `version` numbers in the decorators.
 
@@ -171,8 +180,10 @@ The `API_MIN_VERSION` setting ensures that users can access the API using differ
 
 The generated URLs will be:
 
-- `/api/v1/users`
-- `/api/v2/users`
+```bash
+api/v1/users [name='users_list_api']
+api/v2/users [name='users_list_api']
+```
 
 **Without `version`:** If you don't pass `version` in the decorator, like this:
 
@@ -182,7 +193,9 @@ The generated URLs will be:
 
 API versioning will be disabled (`API_BASE_PATH` as prefix will be removed) for that view. The only URL generated will be:
 
-- `/users`
+```bash
+users [name='users_list_api']
+```
 
 **Setting `backward=False`:** By default, the `backward` parameter is set to `True`, which ensures backward compatibility. If you explicitly set `backward=False`, like this:
 
@@ -192,7 +205,9 @@ API versioning will be disabled (`API_BASE_PATH` as prefix will be removed) for
 
 The generated URL will be only version 2:
 
-- `api/v2/users`
+```bash
+api/v2/users [name='users_list_api']
+```
 
 4. Run the Server:
 
@@ -202,23 +217,56 @@ python manage.py runserver
 
 ## Notes
 
-### 1. `API_BASE_PATH` in settings Must Include ‍‍`{version}`:
+#### 1. `API_BASE_PATH` in settings Must Include ‍‍`{version}`:
 
 The `API_BASE_PATH` should always include `{version}` to ensure proper API versioning. This is important for correctly mapping API routes to different versions.
 
-### 2. Using `app_name` in the `endpoint` decorator:
+#### 2. Using `app_name` in the `endpoint` decorator:
 
 It's recommended to fill in the `app_name` in the `endpoint` decorator to make the API URLs **more unique and organized**. This ensures that the routes are scoped under the correct app, avoiding potential conflicts and making them easier to manage.
 
-### 3. Views with Version Less Than `API_MIN_VERSION` Are Automatically Ignored:
+#### 3. Behavior When Resolving a Route:
+
+When resolving the route using Django's `reverse()` function or any other method to resolve the URL, the latest version (highest version number) of the API will be returned. In this example, route for version 3 would be resolved:
+
+```python
+from django_api_versioning.decorators import endpoint
+from django.http import JsonResponse
+from django.views import View
+from django.urls import reverse
+
+
+@endpoint("users", version=3, app_name='account_app', view_name="users_list_api")
+class UsersView(View):
+
+    def get(self, request):
+
+        return JsonResponse({"path of users_list_api view is": reverse('users_list_api')})
+```
+
+response body:
+
+```json
+{ "path of users_list_api view is": "api/v3/account_app/users" }
+```
+
+The generated URLs will be:
+
+```bash
+api/v1/account_app/users [name='users_list_api']
+api/v2/account_app/users [name='users_list_api']
+api/v3/account_app/users [name='users_list_api']
+```
+
+#### 4. Views with Version Less Than `API_MIN_VERSION` Are Automatically Ignored:
 
 Any view whose `version` is less than the `API_MIN_VERSION` will be automatically ignored. This means clients will no longer have access to these older versions, **without the need to manually edit or remove code**. This is handled automatically by the package.
 
-### 4. URLs for Versions Between `API_MIN_VERSION` <= `version` <= `API_MAX_VERSION`:
+#### 5. URLs for Versions Between `API_MIN_VERSION` <= `version` <= `API_MAX_VERSION`:
 
 Endpoints that have versions within the range defined by `API_MIN_VERSION` <= `version` <= `API_MAX_VERSION` will always have a corresponding URL generated. This ensures that only valid versions will be accessible, providing flexibility in version management.
 
-### `endpoint` Decorator Function Definition
+## `endpoint` Decorator Function Definition
 
 The `endpoint` decorator is designed to register API views with versioning support in a Django application. It provides flexibility in managing versioned endpoints and ensures backward compatibility with previous versions of the API.
 

{django_api_versioning-0.1.2.dist-info → django_api_versioning-0.1.4.dist-info}/RECORD

@@ -1,17 +1,17 @@
 django_api_versioning/__init__.py,sha256=47DEQpj8HBSa-_TImW-5JCeuQeRkm5NMpJWZG3hSuFU,0
-django_api_versioning/decorators.py,sha256=YHyIapxlaQ3IgZnkdjjJ7QXaZxsMFjq-2TY12a5pXAA,3888
+django_api_versioning/decorators.py,sha256=5xWC5gIeDvkaH9UqmLv5eL0FxQ856451_QLMMi_7ex8,4180
 django_api_versioning/exceptions.py,sha256=MgCpaNBsD8laQoVIVK823_t1liQ82K_uqguuA60PxXQ,485
 django_api_versioning/registry.py,sha256=FCRTHGyl995U1kLlxtIBp3lb62v-6AbSK9k3orzZxWA,1140
 django_api_versioning/settings.py,sha256=8p57CIEQR65luxU7xo-eYdH-lSGGk3-BQFMVRRFG2pY,2975
 django_api_versioning/urls.py,sha256=B8UBYSXdyq_xTpWeN5zzH2SQzKiqZQMx3WFBrsu93X0,144
 tests/__init__.py,sha256=47DEQpj8HBSa-_TImW-5JCeuQeRkm5NMpJWZG3hSuFU,0
-tests/test_decorators.py,sha256=G2G3PR_QAPNyJuaw7H9BMARSOK8C6GJlHRAL3KmTuCY,3587
+tests/test_decorators.py,sha256=qtscdA3Sz7eZBwtjSXKBkfOZBcRk2ckm8i1E5t-ihUs,5104
 tests/test_exceptions.py,sha256=fsyfA7ouIMqz6Emexqo_oB7oVEZlhqptNmwH8KX37s8,863
 tests/test_registry.py,sha256=KQT6yWkfKZmcLShFkidHwfJfPi8yHN5i9xuzC3vqDso,2634
 tests/test_settings.py,sha256=SjieOTnwHdU0E6A2-qLE3iXG5osY3qacbAzJJ7tqD-0,5213
 tests/test_urls.py,sha256=DA8DbIEAYX812Re2PlTkL1OpkwCO2IZ1vW_QMh2d9nI,1207
-django_api_versioning-0.1.2.dist-info/LICENSE,sha256=iDPJdze6sBlBBSoB-BIyT2iHfHDGUAaZG3nTFd6m2FQ,1070
-django_api_versioning-0.1.2.dist-info/METADATA,sha256=RquKyi92c11LqbzxUNtIYCEH4ZINWc8g0vf2d4u0SR8,10679
-django_api_versioning-0.1.2.dist-info/WHEEL,sha256=tZoeGjtWxWRfdplE7E3d45VPlLNQnvbKiYnx7gwAy8A,92
-django_api_versioning-0.1.2.dist-info/top_level.txt,sha256=F4n1zaE6P--9OytuMrvCD50vn7NvIVWkIl6ie9fsFck,28
-django_api_versioning-0.1.2.dist-info/RECORD,,
+django_api_versioning-0.1.4.dist-info/LICENSE,sha256=iDPJdze6sBlBBSoB-BIyT2iHfHDGUAaZG3nTFd6m2FQ,1070
+django_api_versioning-0.1.4.dist-info/METADATA,sha256=uqQZKUCxfsrirTnOXWIEEFCIO2EAtjsI9Z2GjLS_VFc,11994
+django_api_versioning-0.1.4.dist-info/WHEEL,sha256=tZoeGjtWxWRfdplE7E3d45VPlLNQnvbKiYnx7gwAy8A,92
+django_api_versioning-0.1.4.dist-info/top_level.txt,sha256=F4n1zaE6P--9OytuMrvCD50vn7NvIVWkIl6ie9fsFck,28
+django_api_versioning-0.1.4.dist-info/RECORD,,

tests/test_decorators.py

@@ -1,10 +1,13 @@
 import pytest
 from unittest.mock import patch
+from django.http import JsonResponse
+from django.views import View
 from django_api_versioning.settings import api_settings as settings
 from django_api_versioning.registry import registry
 from django_api_versioning.decorators import endpoint
 from django_api_versioning.exceptions import InvalidVersionError, VersionTypeError, VersionRangeError
 
+
 @pytest.fixture(autouse=True)
 def clear_registered_routes():
     """Clear the registry before each test to ensure isolation."""
@@ -86,3 +89,34 @@ def test_missing_api_version_settings():
             @endpoint("users", version=2)
             def test_view():
                 pass
+
+def test_class_based_view(mock_settings):
+    # Create a class-based view and decorate it with the `endpoint` decorator
+    @endpoint("users", version=2)
+    class UsersView(View):
+        def get(self, request):
+            return JsonResponse({"message": "API Version 2 Users"})
+
+    # Register the view and check if the route is correctly registered
+    registered_routes = [str(p.pattern) for p in registry.urlpatterns]
+    assert "api/v2/users" in registered_routes, f"Route for version 2 is missing: {registered_routes}"
+
+def test_class_based_view_with_invalid_version(mock_settings):
+    # Test invalid version for class-based view
+    with pytest.raises(InvalidVersionError):
+        @endpoint("users", version=4)
+        class UsersView(View):
+            def get(self, request):
+                return JsonResponse({"message": "API Version 4 Users"})
+
+def test_class_based_view_with_backward_compatibility(mock_settings):
+    # Test class-based view with backward compatibility
+    @endpoint("users", version=3)
+    class UsersView(View):
+        def get(self, request):
+            return JsonResponse({"message": "API Version 3 Users"})
+
+    registered_routes = [str(p.pattern) for p in registry.urlpatterns]
+    # Assert that versions 1, 2, and 3 are registered for backward compatibility
+    for version in range(1, 4):
+        assert f"api/v{version}/users" in registered_routes, f"Missing route for v{version}: {registered_routes}"