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

{django_api_versioning-0.1.3.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.3
+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.3.dist-info → django_api_versioning-0.1.4.dist-info}/RECORD

@@ -10,8 +10,8 @@ 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.3.dist-info/LICENSE,sha256=iDPJdze6sBlBBSoB-BIyT2iHfHDGUAaZG3nTFd6m2FQ,1070
-django_api_versioning-0.1.3.dist-info/METADATA,sha256=qtUKqfKFPH_YbzkBDfydKKnUtCU31gOISnAHX5VtyCY,10679
-django_api_versioning-0.1.3.dist-info/WHEEL,sha256=tZoeGjtWxWRfdplE7E3d45VPlLNQnvbKiYnx7gwAy8A,92
-django_api_versioning-0.1.3.dist-info/top_level.txt,sha256=F4n1zaE6P--9OytuMrvCD50vn7NvIVWkIl6ie9fsFck,28
-django_api_versioning-0.1.3.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,,