Solución:
ACTUALIZAR:
el control de versiones ahora es compatible correctamente.
Hay algunas respuestas de su enlace:
Nos resultó práctico y útil poner la versión en la URL. Hace que sea fácil saber lo que está usando de un vistazo. Hacemos alias / foo a / foo / (últimas versiones) para facilitar el uso, URL más cortas / más limpias, etc., como sugiere la respuesta aceptada. Mantener la compatibilidad con versiones anteriores para siempre es a menudo un costo prohibitivo y / o muy difícil. Preferimos dar un aviso anticipado de la desaprobación, redireccionamientos como se sugiere aquí, documentos y otros mecanismos.
Así que adoptamos este enfoque, además de permitir que los clientes especifiquen la versión en el encabezado de la solicitud (Versión X), así es como lo hicimos:
Estructura en el lado de la aplicación API:
.
├── __init__.py
├── middlewares.py
├── urls.py
├── v1
│ ├── __init__.py
│ ├── account
│ │ ├── __init__.py
│ │ ├── serializers.py
│ │ └── views.py
│ └── urls.py
└── v2
├── __init__.py
├── account
│ ├── __init__.py
│ ├── serializers.py
│ └── views.py
└── urls.py
proyecto urls.py:
url(r'^api/', include('project.api.urls', namespace="api")),
URL de nivel de aplicación api.py:
from django.conf.urls import *
urlpatterns = patterns('',
url(r'', include('project.api.v2.urls', namespace="default")),
url(r'^v1/', include('project.api.v1.urls', namespace="v1")),
)
nivel de versión urls.py
from django.conf.urls import *
from .account import views as account_views
from rest_framework.routers import DefaultRouter
router = DefaultRouter()
router.register('account', account_views.AccountView)
router.register('myaccount', account_views.MyAccountView)
urlpatterns = router.urls
cree un middleware para cambiar al código correcto cambiando path_info, tenga en cuenta que hay una advertencia de que el espacio de nombres (‘api’) definido en las URL de nivel de proyecto no es flexible y debe conocerse en middleware:
from django.core.urlresolvers import resolve
from django.core.urlresolvers import reverse
class VersionSwitch(object):
def process_request(self, request):
r = resolve(request.path_info)
version = request.META.get('HTTP_X_VERSION', False)
if r.namespace.startswith('api:') and version:
old_version = r.namespace.split(':')[-1]
request.path_info = reverse('{}:{}'.format(r.namespace.replace(old_version, version), r.url_name), args=r.args, kwargs=r.kwargs)
URL de muestra:
curl -H "X-Version: v1" http://your.domain:8000/api/myaccount/
Una forma de hacerlo es especificar el control de versiones como parte del tipo de medio.
Esto es lo que GitHub hace actualmente por su API.
También puede incluir parámetros de tipo de medio en sus encabezados de aceptación, p. Ej. Accept: application/json; version=beta, que coincidirá con éxito contra JSONRenderer. Luego, puede codificar su vista para que se comporte de manera diferente según el tipo de medio aceptado, consulte aquí.
Hay muchos patrones diferentes para el control de versiones en las API, y no diría que todavía hay un gran consenso sobre el enfoque correcto, pero esa sería una posibilidad razonable.
Actualización de enero de 2015: En la versión 3.1.0 habrá un mejor soporte de versiones. Ver [this pull request]
Actualización de marzo de 2015: Los documentos para la API de control de versiones ya están disponibles.
(https://github.com/tomchristie/django-rest-framework/pull/2285) para obtener más detalles.