django---05---响应和中间件-蒲公英云

一：响应：
1：常见的响应：
HttpResponse()：响应多种数据类型
JsonResponse()：响应JSON
redirect()：重定向
render()：渲染并响应HTML模板

2：HttpResponse():
格式：response = HttpResponse(content=响应体, content_type=响应体数据类型，默认为text/html, status=状态码，默认为200)
Django提供了一系列HttpResponse的子类，可以快速设置状态码

HttpResponseRedirect 默认响应状态码为 301
HttpResponsePermanentRedirect 默认响应状态码为 302
HttpResponseNotModified 默认响应状态码为 304
HttpResponseBadRequest 默认响应状态码为 400
HttpResponseNotFound 默认响应状态码为 404
HttpResponseForbidden 默认响应状态码为 403
HttpResponseNotAllowed 默认响应状态码为 405
HttpResponseGone 默认响应状态码为 410
HttpResponseServerError 默认响应状态码为 500

3：JsonResponse()：响应JSON：
函数的作用：

1：帮助我们将响应的数据转换为JSON字符串
2：设置响应头Content-Type为 application/json
# 构造响应信息：
class JSONResponseView(View):
    def get(self,request):
        dict_data = {
            'username':"任善文",
            'age':'23'
        }
        return http.JsonResponse(dict_data)
path("response/",views.JSONResponseView.as_view()),

4：redirect()：重定向
需求：
准备一个用于处理用户登录类视图LoginRedirectView。
访问LoginRedirectView时，如果其中的登录逻辑处理完成，我们将用户重定向到首页。

class IndexView(View):
    def get(self,request):
        return http.HttpResponse("假定这是个首页")
class LoginView(View):
    def post(self,request):
        return redirect('/index/')
path("index/",views.IndexView.as_view()),
    path("login/",views.LoginView.as_view()),

5：反向解析：
我们定义的路由中的地址是否可能会做修改？
如果我们定义的路由中的地址在某次开发新版本时被修改了，那么重定向的地方是否也需要跟着改变？
如果该地址被很多地方都用到了，那么是否就意味着我们要修改代码的很多地方？

答案：路由反向解析
路由反向解析是使用路由的别名，动态的解析出该路由中的真实地址
格式：
总路由起别名：
path(“ ‘’, include((‘子路由’, ‘子应用名字’), namespace=‘总路由别名，可以随便命名’)),
子路由起别名：
path(‘index/’, views.IndexView.as_view(), name=‘index’),

案例：
1：总路由起别名：path("",include(("request_response.urls","request_response"),namespace="request_response"))
2：子路由起别名：

path("index/",views.IndexView.as_view(),name="index"),

3：视图中使用别名：

lass LoginView(View):
    def post(self,request):
        ret_str = reverse("request_response:index")
        return redirect(ret_str)

二：中间件：
**Django中的中间件是一个轻量级、底层的插件系统，可以介入Django的请求和响应处理过程，修改Django的输入或输出。中间件的设计为开发者提供了一种无侵入式的开发方式，增强了Django框架的健壮性，其它的MVC框架也有这个功能。**当某些操作在每次请求或响应时都会执行时，可以写在中间件中。比如，每次发送post请求都要进行CSRF验证，就把CSRF验证的代码写在中间件中。

中间件的方法：
2.2 处理请求前的方法：(重要)
在处理每个请求前，自动调用，返回None或HttpResponse对象

def process_request(self, request):

2.3 处理视图前的方法：（重要）
在处理每个视图前，自动调用，返回None或HttpResponse对象

def process_view(self, request, view_func, view_args, view_kwargs):

2.4 处理模板响应前的方法：
在处理每个模板响应前，自动调用，返回实现了render方法的响应对象

def process_template_response(self, request, response):

2.5 处理响应后的方法：（重要）
在每个响应返回给客户端之前，自动调用，返回HttpResponse对象

def process_response(self, request, response):

2.6 异常处理：
当视图抛出异常时，自动调用，返回一个HttpResponse对象

def process_exception(self, request,exception):

三：自定义中间件：
1：定义中间件类：
2：注册自定义的中间件：

# 导入中间件的父类
from django.utils.deprecation import MiddlewareMixin
class TestMiddleware1(MiddlewareMixin):
    """自定义中间件"""
    def process_request(self, request):
        """处理请求前自动调用"""
        print('process_request1 被调用')
    def process_view(self, request, view_func, view_args, view_kwargs):
        # 处理视图前自动调用
        print('process_view1 被调用')
    def process_response(self, request, response):
        """在每个响应返回给客户端之前自动调用"""
        print('process_response1 被调用')
        return response
MIDDLEWARE = [
    'django.middleware.security.SecurityMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.common.CommonMiddleware',
    # 为保证非GET请求(POST, PUT, DELETE)可以正常接收，该中间件需要注释掉
    # 'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'django.middleware.clickjacking.XFrameOptionsMiddleware',
    'middlewares.TestMiddleware1', # 注册自定义的中间件1
]

四：多个中间件执行流程测试：
假如定义两个上面的中间件：

from django.utils.deprecation import MiddlewareMixin
class TestMiddleware1(MiddlewareMixin):
    def __init__(self, get_response=None):
        print("中间件1的初始化")
        super().__init__(get_response)
    """自定义中间件"""
    def process_request(self, request):
        """处理请求前自动调用"""
        print('process_request1 被调用')
    def process_view(self, request, view_func, view_args, view_kwargs):
        # 处理视图前自动调用
        print('process_view1 被调用')
    def process_response(self, request, response):
        """在每个响应返回给客户端之前自动调用"""
        print('process_response1 被调用')
        return response
class TestMiddleware2(MiddlewareMixin):
    def __init__(self, get_response=None):
        print("中间件2的初始化")
        super().__init__(get_response)
    """自定义中间件"""
    def process_request(self, request):
        """处理请求前自动调用"""
        print('process_request2 被调用')
    def process_view(self, request, view_func, view_args, view_kwargs):
        # 处理视图前自动调用
        print('process_view2 被调用')
    def process_response(self, request, response):
        """在每个响应返回给客户端之前自动调用"""
        print('process_response2 被调用')
        return response
'middlewares.TestMiddleware1', # 注册自定义的中间件1
'middlewares.TestMiddleware2',  # 注册自定义的中间件2

测试结果：

中间件2的初始化
中间件1的初始化
process_request1 被调用
process_request2 被调用
process_view1 被调用
process_view2 被调用
process_response2 被调用
process_response1 被调用

分析：
1：对于初始化来说，时间是整个django启动时就进行初始化，此时中间件逆序初始化。
2：对于请求调用来说，是顺序调用中间件。
3：对于响应调用来说，是逆序调用。
在这里插入图片描述
分析：中间件本质就是装饰器，装饰器装饰过程是先装饰距离自己近的，所以初始化顺序是逆序，距离近的是后写的。对于调用过程，先调用前面的中间件，再调用后面的中间件，最后执行视图。执行完后，再调用后面的中间件，最后调用前面的。这就类似装饰器先正向传值，然后再反向return。