版本控制
from rest_framework.versioning import QueryParameterVersioning,AcceptHeaderVersioning,NamespaceVersioning,URLPathVersioning #基于url的get传参方式：QueryParameterVersioning------>如：/users?version=v1 #基于url的正则方式：URLPathVersioning------>/v1/users/ #基于 accept 请求头方式：AcceptHeaderVersioning------>Accept: application/json; version=1.0 #基于主机名方法：HostNameVersioning------>v1.example.com #基于django路由系统的namespace：NamespaceVersioning------>example.com/v1/users/
-内置的类
QueryParameterVersioning, 基于get传参的方式
AcceptHeaderVersioning,基于请求头的
NamespaceVersioning, 基于名称空间的
URLPathVersioning 基于正则的方式(推荐)
-局部使用
在视图类中配置
versioning_class=URLPathVersioning
-全局使用
在setting中配置:
‘DEFAULT_VERSIONING_CLASS‘:‘rest_framework.versioning.URLPathVersioning‘,
‘DEFAULT_VERSION‘: ‘v1‘, # 默认版本(从request对象里取不到，显示的默认值)
‘ALLOWED_VERSIONS‘: [‘v1‘, ‘v2‘], # 允许的版本
‘VERSION_PARAM‘: ‘version‘ # URL中获取值的key
-例外:
用基于正则的方式,需要修改urls.py
url(r‘^(?P<version>[v1|v2]+)/versiontest/‘, views.VersionTest.as_view()),
-在视图类的方法中可以取出版本号
reques.version
基于正则的方式：
from django.conf.urls import url, include
from web.views import TestView
urlpatterns = [
url(r‘^(?P<version>[v1|v2]+)/test/‘, TestView.as_view(), name=‘test‘),
]
from rest_framework.views import APIView
from rest_framework.response import Response
from rest_framework.versioning import URLPathVersioning
class TestView(APIView):
versioning_class = URLPathVersioning
def get(self, request, *args, **kwargs):
# 获取版本
print(request.version)
# 获取版本管理的类
print(request.versioning_scheme)
# 反向生成URL
reverse_url = request.versioning_scheme.reverse(‘test‘, request=request)
print(reverse_url)
return Response(‘GET请求，响应内容‘)
# 基于django内置,反向生成url
from django.urls import reverse
url2=reverse(viewname=‘ttt‘,kwargs={‘version‘:‘v2‘})
print(url2)
同源策略（Same origin policy）是一种约定，它是浏览器最核心也最基本的安全功能，如果缺少了同源策略，则浏览器的正常功能可能都会受到影响。可以说Web是构建在同源策略基础之上的，浏览器只是针对同源策略的一种实现
请求的url地址,必须与浏览器上的url地址处于同域上,也就是域名,端口,协议相同.
比如:我在本地上的域名是127.0.0.1:8000,请求另外一个域名：127.0.0.1:8001一段数据
浏览器上就会报错，个就是同源策略的保护,如果浏览器对javascript没有同源策略的保护,那么一些重要的机密网站将会很危险
已拦截跨源请求：同源策略禁止读取位于 http://127.0.0.1:8001/SendAjax/ 的远程资源。（原因：CORS 头缺少 ‘Access-Control-Allow-Origin‘）。
但是注意，项目2中的访问已经发生了，说明是浏览器对非同源请求返回的结果做了拦截
CORS需要浏览器和服务器同时支持。目前，所有浏览器都支持该功能，IE浏览器不能低于IE10。
整个CORS通信过程，都是浏览器自动完成，不需要用户参与。对于开发者来说，CORS通信与同源的AJAX通信没有差别，代码完全一样。浏览器一旦发现AJAX请求跨源，就会自动添加一些附加的头信息，有时还会多出一次附加的请求，但用户不会有感觉。
因此，实现CORS通信的关键是服务器。只要服务器实现了CORS接口，就可以跨源通信。
浏览器将CORS请求分成两类：简单请求（simple request）和非简单请求（not-so-simple request）。
浏览器发出CORS简单请求，只需要在头信息之中增加一个Origin字段。
浏览器发出CORS非简单请求，会在正式通信之前，增加一次HTTP查询请求，称为"预检"请求（preflight）。浏览器先询问服务器，当前网页所在的域名是否在服务器的许可名单之中，以及可以使用哪些HTTP动词和头信息字段。只有得到肯定答复，浏览器才会发出正式的XMLHttpRequest请求，否则就报错。
只要同时满足以下两大条件，就属于简单请求。
（1) 请求方法是以下三种方法之一： HEAD GET POST （2）HTTP的头信息不超出以下几种字段： Accept Accept-Language Content-Language Last-Event-ID Content-Type：只限于三个值application/x-www-form-urlencoded、multipart/form-data、text/plain
凡是不同时满足上面两个条件，就属于非简单请求。
浏览器对这两种请求的处理，是不一样的。
* 简单请求和非简单请求的区别？
简单请求：一次请求
非简单请求：两次请求，在发送数据之前会先发一次请求用于做“预检”，只有“预检”通过后才再发送一次请求用于数据传输。
* 关于“预检”
- 请求方式：OPTIONS
- “预检”其实做检查，检查如果通过则允许传输数据，检查不通过则不再发送真正想要发送的消息
- 如何“预检”
=> 如果复杂请求是PUT等请求，则服务端需要设置允许某请求，否则“预检”不通过
Access-Control-Request-Method
=> 如果复杂请求设置了请求头，则服务端需要设置允许某请求头，否则“预检”不通过
Access-Control-Request-Headers
支持跨域，简单请求
服务器设置响应头：Access-Control-Allow-Origin = ‘域名‘ 或 ‘*‘
支持跨域，复杂请求
由于复杂请求时，首先会发送“预检”请求，如果“预检”成功，则发送真实数据。
def test(request):
import json
obj=HttpResponse(json.dumps({‘name‘:‘lqz‘}))
# obj[‘Access-Control-Allow-Origin‘]=‘*‘
obj[‘Access-Control-Allow-Origin‘]=‘http://127.0.0.1:8004‘
return obj
放到中间件处理复杂和简单请求： 将自定义类的位置放入中间件
from django.utils.deprecation import MiddlewareMixin
class CorsMiddleWare(MiddlewareMixin): def process_response(self,request,response): if request.method=="OPTIONS": #可以加* response["Access-Control-Allow-Headers"]="Content-Type" response["Access-Control-Allow-Origin"] = "http://localhost:8080" return response
# 基于django内置,反向生成url
from django.urls import reverse
url2=reverse(viewname=‘ttt‘,kwargs={‘version‘:‘v2‘})
print(url2)
原文：https://www.cnblogs.com/wrqysrt/p/10645256.html