1 前言
Django使用非常熟练了,各种API接口不在话下,全都搞定。为方便定位问题在每个API接口的的开始和返回的地方都加上了log打印,记录入参和返回值。
但是这样有一个问题,需要每个API接口都要写一遍,非常的不Pythonic,有没有更好的方法呢?
如果大家对装饰器熟悉的话,会想到这个方法。写一个log_wrapper,在每个API的函数上写上@log_wrapper,这样看起来比较美观了。但是有一个问题,如果那个接口忘记使用这个装饰器了,日志就无法记录了。
在Django中有没有更好的解决方案呢,答案是肯定的。
2 Django HTTP处理流程
2.1 HTTP处理流程
我们先来熟悉下Django的HTTP处理流程,详细的处理流程请看下图。
每个HTTP请求过来,先经过request middleware处理,如果没有异常,则交由URLConf处理(即urls.py文件)来匹配URL,然后到view middleware处理,最后到具体的view业务函数。
HTTP请求中间处理的每个步骤,如果发生异常,直接返回response,而不是到下一个流程中。可以看到图中每个步骤都可以返回response。
2.2 Request和Response对象
在Django中,一个 HTTP 请求,首先被转化成一个 HttpRequest 对象,然后该对象被传递给 Request middleware处理,如果该middleware返回了Response,则生成一个Response对象,里面包含所有的HTTP 响应元素。
HttpRequest对象的属性
Attribute | Description |
path | 请求页面的全路径,不包括域名—例如, "/music/bands/the_beatles/"。 |
method | 请求中使用的HTTP方法的字符串表示。全大写表示。例如: if request.method == 'GET': |
GET | 包含所有HTTP GET参数的类字典对象。参见QueryDict 文档。 |
POST | 包含所有HTTP POST参数的类字典对象。参见QueryDict 文档。 服务器收到空的POST请求的情况也是有可能发生的。也就是说,表单form通过HTTP POST方法提交请求,但是表单中可以没有数据。因此,不能使用语句if request.POST来判断是否使用HTTP POST方法;应该使用if request.method == "POST" (参见本表的method属性)。 注意: POST不包括file-upload信息。参见FILES属性。 |
REQUEST | 为了方便,该属性是POST和GET属性的集合体,但是有特殊性,先查找POST属性,然后再查找GET属性。借鉴PHP’s $_REQUEST。 例如,如果GET = {"name": "john"} 和POST = {"age": '34'},则 REQUEST["name"] 的值是"john", REQUEST["age"]的值是"34". 强烈建议使用GET and POST,因为这两个属性更加显式化,写出的代码也更易理解。 |
COOKIES | 包含所有cookies的标准Python字典对象。Keys和values都是字符串。参见第12章,有关于cookies更详细的讲解。 |
FILES | 包含所有上传文件的类字典对象。FILES中的每个Key都是<input type="file" name="" />标签中name属性的值. FILES中的每个value 同时也是一个标准Python字典对象,包含下面三个Keys:
注意:只有在请求方法是POST,并且请求页面中<form>有enctype="multipart/form-data"属性时FILES才拥有数据。否则,FILES 是一个空字典。 |
META | 包含所有可用HTTP头部信息的字典。 例如:
META 中这些头加上前缀HTTP_最为Key, 例如:
|
user | 是一个django.contrib.auth.models.User 对象,代表当前登录的用户。如果访问用户当前没有登录,user将被初始化为django.contrib.auth.models.AnonymousUser的实例。你可以通过user的is_authenticated()方法来辨别用户是否登录: if request.user.is_authenticated(): 只有激活Django中的AuthenticationMiddleware时该属性才可用 关于认证和用户的更详细讲解,参见第12章。 |
session | 唯一可读写的属性,代表当前会话的字典对象。只有激活Django中的session支持时该属性才可用。 参见第12章。 |
raw_post_data | 原始HTTP POST数据,未解析过。 高级处理时会有用处。 |
Response对象
Attribute | Description |
path | 请求页面的全路径,不包括域名—例如, "/music/bands/the_beatles/"。 |
method | 请求中使用的HTTP方法的字符串表示。全大写表示。例如: if request.method == 'GET': |
GET | 包含所有HTTP GET参数的类字典对象。 |
status_code | HTTP 状态码 |
content | 返回的内容 |
| 其他内容略 |
Django的Response返回类型比较多,基本都是继承了HTTPResponse这个类。
3 Django中间件介绍和分析
根据上面的HTTP处理流程图,有一个想法,把每个请求和返回的日志记录加到middleware中,这样每个HTTP的请求和返回都可以记录到。并且不影响业务函数的编写和美观。
该如何使用middleware呢?
我们来看下Django的中间件是如何处理HTTP请求的。如下图。
上面中间件不是每个项目必须的,在Django中是可选的,配置在settings.py文件的MIDDLEWARE配置中。可以根据需要进行增加和删除。
3.1 Middleware使用
在Django中,middleware的配置在settings文件中,
MIDDLEWARE = [ 'django.middleware.security.SecurityMiddleware', 'django.contrib.sessions.middleware.SessionMiddleware', 'django.middleware.common.CommonMiddleware', 'django.middleware.csrf.CsrfViewMiddleware', 'django.contrib.auth.middleware.AuthenticationMiddleware', 'django.contrib.messages.middleware.MessageMiddleware', 'django.middleware.clickjacking.XFrameOptionsMiddleware', ]
Middleware调用是有序和分层的,request是从上到下,response则相反。
我们现在看下django自带的中间件是什么样子的。
查看django源码: site-packages\django\middleware\common.py中的CommonMiddleware的类。
发现继承了MiddlewareMixin类。
class CommonMiddleware(MiddlewareMixin): response_redirect_class = http.HttpResponsePermanentRedirect
def process_request(self, request): """ Check for denied User-Agents and rewrite the URL based on settings.APPEND_SLASH and settings.PREPEND_WWW """ # Check for denied User-Agents if 'HTTP_USER_AGENT' in request.META: for user_agent_regex in settings.DISALLOWED_USER_AGENTS: if user_agent_regex.search(request.META['HTTP_USER_AGENT']): raise PermissionDenied('Forbidden user agent') # Check for a redirect based on settings.PREPEND_WWW host = request.get_host() must_prepend = settings.PREPEND_WWW and host and not host.startswith('www.') redirect_url = ('%s://www.%s' % (request.scheme, host)) if must_prepend else '' # Check if a slash should be appended if self.should_redirect_with_slash(request): path = self.get_full_path_with_slash(request) else: path = request.get_full_path() # Return a redirect if necessary if redirect_url or path != request.get_full_path(): redirect_url += path return self.response_redirect_class(redirect_url) def should_redirect_with_slash(self, request): """ Return True if settings.APPEND_SLASH is True and appending a slash to the request path turns an invalid path into a valid one. """ if settings.APPEND_SLASH and not request.get_full_path().endswith('/'): urlconf = getattr(request, 'urlconf', None) return ( not is_valid_path(request.path_info, urlconf) and is_valid_path('%s/' % request.path_info, urlconf) ) return False def get_full_path_with_slash(self, request): """ Return the full path of the request with a trailing slash appended. Raise a RuntimeError if settings.DEBUG is True and request.method is POST, PUT, or PATCH. """ new_path = request.get_full_path(force_append_slash=True) if settings.DEBUG and request.method in ('POST', 'PUT', 'PATCH'): raise RuntimeError( "You called this URL via %(method)s, but the URL doesn't end " "in a slash and you have APPEND_SLASH set. Django can't " "redirect to the slash URL while maintaining %(method)s data. " "Change your form to point to %(url)s (note the trailing " "slash), or set APPEND_SLASH=False in your Django settings." % { 'method': request.method, 'url': request.get_host() + new_path, } ) return new_path def process_response(self, request, response): """ Calculate the ETag, if needed. When the status code of the response is 404, it may redirect to a path with an appended slash if should_redirect_with_slash() returns True. """ # If the given URL is "Not Found", then check if we should redirect to # a path with a slash appended. if response.status_code == 404: if self.should_redirect_with_slash(request): return self.response_redirect_class(self.get_full_path_with_slash(request)) if settings.USE_ETAGS: if not response.has_header('ETag'): set_response_etag(response) if response.has_header('ETag'): return get_conditional_response( request, etag=unquote_etag(response['ETag']), response=response, ) return response
查看Mixin类,有两个函数:
self.process_request(request)
self.porcess_response(request, response)
这两个函数:
class MiddlewareMixin(object): def __init__(self, get_response=None): self.get_response = get_response super(MiddlewareMixin, self).__init__() def __call__(self, request): response = None if hasattr(self, 'process_request'): response = self.process_request(request) if not response: response = self.get_response(request) if hasattr(self, 'process_response'): response = self.process_response(request, response) return response
有了这些信息,我们来实现自己的middleware
3.2 自定义日志middleware
在apps/common/文件夹下创建middleware.py文件
from django.utils.deprecation import MiddlewareMixin from rest_framework.response import Response from django.http import JsonResponse import logging jira_log = logging.getLogger('debug') class Reponse(MiddlewareMixin): def process_response(self, request, response): if isinstance(response, Response) and response.get('content-type') == 'application/json' and \ isinstance(response.data, dict): response.data['msg'] = '成功' response.content = response.rendered_content # self._convert_data(response, 200) if isinstance(response, JsonResponse): jira_log.debug(response.content) return response @staticmethod def process_request(request): if request.method == 'POST': jira_log.debug(request.body) if request.method == 'GET': jira_log.debug(request.GET) setattr(request, '_dont_enforce_csrf_checks', True)
可以看到,我们自己实现了process_request 、process_response 两个函数,增加了日志打印。这样每个请求和返回都有日志记录。
2017-12-13 14:12:04,520 [middleware.py: 39][Thread-7 ][debug ]DEBUG request: b'{"a":1, "b":2}' 2017-12-13 14:12:04,530 [middleware.py: 31][Thread-7 ][debug ]DEBUG response {'status': 200, 'msg': '成功'} 2017-12-13 14:12:21,071 [middleware.py: 41][Thread-8 ][debug ]DEBUG request: <QueryDict: {}> 2017-12-13 14:12:21,074 [middleware.py: 31][Thread-8 ][debug ]DEBUG response {'status': 200, 'msg': '成功'} 2017-12-13 14:12:44,432 [middleware.py: 41][Thread-9 ][debug ]DEBUG request: <QueryDict: {}> 2017-12-13 14:12:44,434 [middleware.py: 33][Thread-9 ][debug ]DEBUG response b'{"status": 200, "msg": "\\u6210\\u529f 1"}'
3.3 使用自定义的middleware
在middleware的配置中添加自定义middleware类即可。
MIDDLEWARE = [ 'django.middleware.security.SecurityMiddleware', 'django.contrib.sessions.middleware.SessionMiddleware', # 自定义的middleware,记录日志, 'apps.common.middleware.Reponse', 'django.middleware.common.CommonMiddleware', 'django.middleware.csrf.CsrfViewMiddleware', 'django.contrib.auth.middleware.AuthenticationMiddleware', 'django.contrib.messages.middleware.MessageMiddleware', 'django.middleware.clickjacking.XFrameOptionsMiddleware', ]
PS:中间放置的位置是顺序是有要求的,request请求是按照从上到下的顺序处理。放置的位置要根据中间件的功能和实际要求来分析。
3.4 实测日志记录
发送几个请求来查看日志的记录情况:
2017-12-13 14:12:04,520 [middleware.py: 39][Thread-7 ][debug ]DEBUG request: b'{"a":1, "b":2}' 2017-12-13 14:12:04,530 [middleware.py: 31][Thread-7 ][debug ]DEBUG response {'status': 200, 'msg': '成功'} 2017-12-13 14:12:21,071 [middleware.py: 41][Thread-8 ][debug ]DEBUG request: <QueryDict: {}> 2017-12-13 14:12:21,074 [middleware.py: 31][Thread-8 ][debug ]DEBUG response {'status': 200, 'msg': '成功'} 2017-12-13 14:12:44,432 [middleware.py: 41][Thread-9 ][debug ]DEBUG request: <QueryDict: {}> 2017-12-13 14:12:44,434 [middleware.py: 33][Thread-9 ][debug ]DEBUG response b'{"status": 200, "msg": "\\u6210\\u529f 1"}'
日志能准确的记录请求的参数和返回的内容。当然也可以记录更详细的情况,这个可以根据需要进行添加。
4 中间件之process_view
Process_view处理也是middleware的一个函数,专门用来处理view,访问顺序在request之后,业务view函数之前。
process_view(self, request, callback, callback_args, callback_kwargs)
在middleware文件中的的代码进行更改:增加process_view代码,并打印日志
发现middleware的处理顺序为request-view-response。
如果有多个middleware,则日志打印顺序为:
- Request1
- Request2
- Request3
- middlewareView1
- middlewareView2
- middlewareView3
- API view
- Response3
- Response2
- Response1
有兴趣的同学可以自己写下看看。
5 Middleware应用
根据Django官方定义,middleware是框架的钩子。
Middleware is a framework of hooks into Django’s request/response processing. It’s a light, low-level “plugin” system for globally altering Django’s input or output.
了解了middleware的原理,我们可以做许多事情。
5.1 规范化response
很多项目使用了rest-framework框架,框架对于异常的处理有两点与我们规范不一致:
l status_code是400,与我们定义的规范不符合,
l 处理成功时,返回json中的msg字段值为:成功。
l 数据都放到data字段中
如果我们手动处理,则每个人都要来适配这样的格式。
感谢成宇为大家实现了response的格式化的middleware。简化了大家的工作。
例如在众测平台,就使用middleware来规范response输出,把不符合规范的格式整理为:
{ "msg": "成功", "status": 200, "data": { "data": "our data" } }
5.2 用来记录响应时间
可以根据请求和响应时间,记录接口的性能。
5.3 中间件其他作用
- 可以用来整理请求,统一添加某个字段。
- 用来整理返回,统一添加某个字段。
- 还可以动态添加访问黑名单,判断IP地址是否可以访问。
- 收集访问来源类型,是PC还是手机浏览器。
这些都可以和具体的业务解耦,全局的配置。
当然有些功能在nginx配置比较好。例如IP黑名单。
6 参考资料
编号 | 资料名称 | 链接 |
1 | Django官方文档 | https://docs.djangoproject.com/en/2.0/ref/ |
2 | Request和response对象 | http://blog.csdn.net/liu_yanna/article/details/50174851 |
3 | Django底层剖析之一次请求到响应的整个流程 | https://www.cnblogs.com/wanghzh/p/5831992.html |
|
|
|