request.POST # 只处理表单数据 只适用于‘POST‘方法
request.data # 处理任意数据 适用于‘POST‘，‘PUT‘和‘PATCH‘方法
REST framework 传入视图的request对象不再是Django默认的HttpRequest对象，而是REST framework提供的扩展了HttpRequest类的Request类的对象。
REST framework 提供了Parser解析器，在接收到请求后会自动根据Content-Type指明的请求数据类型（如JSON、表单等）将请求数据进行parse解析，解析为类字典[QueryDict]对象保存到Request对象中。
Request对象的数据是自动根据前端发送数据的格式进行解析之后的结果。
无论前端发送的哪种格式的数据，我们都可以以统一的方式读取数据。
request.data 返回解析之后的请求体数据。类似于Django中标准的request.POST和 request.FILES属性，但提供如下特性：
request.query_params与Django标准的request.GET相同，只是更换了更正确的名称而已。
request.query_params是request.GET的一个更准确的同义词。为了让你的代码清晰明了, 我们建议使用
request.query_params而不是Django标准的request.GET。这样做有助于保持代码库更加正确和明了——任何HTTP方法类型可能包括查询参数，而不仅仅是GET请求。
注意Note: 如果客户端发送格式错误的内容，则访问request.data可能会引发ParseError。默认情况下REST framework的 APIView类或@api_view装饰器将捕获错误并返回400 Bad Request响应。
如果客户端发送具有无法解析的呃逆荣类型的请求，则会引发 UnsupportedMediaType 异常, 默认情况下会捕获该异常并返回 415 Unsupported Media Type 响应。
请求提供了一些属性允许你确定内容协商阶段的结果。这允许你实现具体的行为，例如为不同的媒体类型选择不用的序列化方案。
由内容协商阶段选择的render实例。
由内容协商阶段接受的媒体类型的字符串。
REST framework 提供了灵活的，每次请求的验证，让你能够： * 对API的不同部分使用不同的身份验证策略。 * 支持使用多个身份验证策略。 * 提供与传入请求相关联的用户和令牌信息。
request.user 通常返回一个 django.contrib.auth.models.User 实例, 尽管该行为取决于所使用的的认证策略。
如果请求未认证则 request.user 的默认值为 django.contrib.auth.models.AnonymousUser的一个实例。
更多详细信息请查阅 authentication documentation.
request.auth 返回任何其他身份验证上下文。 request.auth 的确切行为取决于所使用的的认证策略，但它通常可以是请求被认证的token的实例。
如果请求未认证或者没有其他上下文，则 request.auth 的默认值为 None.
更多详细信息请查阅 authentication documentation.
APIView 类或 @api_view 装饰器将根据在view中设置的 authentication_classes 或基于DEFAULT_AUTHENTICATORS 设置，确保此属性自动设置为 Authentication 实例的列表。
你通常并不需要访问此属性。
REST framework 支持一些浏览器增强功能，例如基于浏览器的 PUT, PATCH 和 DELETE 表单。
request.method 返回请求的HTTP方法的 大写 字符串表示形式。
透明地支持基于浏览器的 PUT, PATCH 和 DELETE 表单。
更多详细信息请查阅 browser enhancements documentation.
request.content_type 返回表示HTTP请求正文的媒体类型的字符串对象，如果未提供媒体类型，则返回空字符串。
你通常不需要直接访问请求的内容类型，因为你通常将依赖于REST framework的默认请求解析行为。
如果你确实需要访问请求的内容类型，你应该使用 .content_type 属性，而不是使用 request.META.get(‘HTTP_CONTENT_TYPE‘), 因为它为基于浏览器的非表单内容提供了透明的支持。
更多详细信息请查阅 browser enhancements documentation.
request.stream 返回一个表示请求主体内容的流。
你通常不需要直接访问请求的内容类型，因为你通常将依赖于REST framework的默认请求解析行为。
由于 REST framework 的 Request 扩展了 Django的 HttpRequest, 所以所有其他标准属性和方法也是可用的。例如 request.META 和 request.session 字典正常可用。
请注意，由于实现原因， Request 类并不会从 HttpRequest 类继承, 而是使用合成扩展类。
rest_framework.response.Response
REST framework提供了一个响应类Response，使用该类构造响应对象时，响应的具体数据内容会被转换（render渲染）成符合前端需求的类型。
REST framework提供了Renderer 渲染器，用来根据请求头中的Accept（接收数据类型声明）来自动转换响应数据到对应格式。如果前端请求中未进行Accept声明，则会采用默认方式处理响应数据，我们可以通过配置来修改默认响应格式。
Response 类是 Django中 SimpleTemplateResponse 类的一个子类。Response 对象用Python基本数据类型初始化。 然后REST framework 使用标准的HTTP content negotiation 来确定如何呈现最终的响应内容。
你并不需要一定是用 Response 类，你可以从你的视图返回常规的 HttpResponse 或者 StreamingHttpResponse 对象。使用Response类只提供了一个可以呈现多种格式的更好的界面来返回 content-negotiated 的 Web API 响应。
除非由于某种原因你要对 REST framework 做大量的自定义，否则你应该始终对返回对象的views使用 APIView 类或者 @api_view 函数。这样做可以确保视图在返回之前能够执行 content negotiation 并且为响应选择适当的渲染器。
可以在rest_framework.settings查找所有的drf默认配置项
REST_FRAMEWORK = {
‘DEFAULT_RENDERER_CLASSES‘: ( # 默认响应渲染类
‘rest_framework.renderers.JSONRenderer‘, # json渲染器
‘rest_framework.renderers.BrowsableAPIRenderer‘, # 浏览API渲染器
)
}
Response(data, status=None, template_name=None, headers=None, content_type=None)
data数据不能是render处理之后的数据，只需传递python的内建类型数据即可(未渲染的数据)，REST framework会使用renderer渲染器处理data。
data不能是复杂结构的数据，如Django的模型类对象，对于这样的数据我们可以使用Serializer序列化器序列化处理后（转为了Python字典类型）再传递给data参数。
参数说明：
data: 为响应准备的序列化处理后的数据；status: 状态码，默认200；template_name: 模板名称，如果使用HTMLRenderer 时需指明；headers: 用于存放响应头信息的字典；content_type: 响应数据的Content-Type，通常此参数无需传递，REST framework会根据前端所需类型数据来设置该参数。1）.data : 传给response对象的序列化后，但尚未render处理的数据(未渲染)
2）.status_code: HTTP 响应 状态码的数字
3）.content: 经过render处理后的响应数据, .render() 方法必须先调用才能访问 .content 。
了解的属性：
template_name 只有在使用 HTMLRenderer 或者其他自定义模板作为response的渲染器时才需要提供该属性。
将用于呈现response的render实例。
自动通过 APIView 或者 @api_view 在view返回response之前设置。
由 content negotiation 阶段选择的媒体类型。
自动通过 APIView 或者 @api_view 在view返回response之前设置。
一个将传递给渲染器的.render()方法的附加上下文信息字典。
自动通过 APIView 或者 @api_view 在view返回response之前设置。
Response 类扩展了 SimpleTemplateResponse，并且所有常用的属性和方法都是提供的。比如你可以使用标准的方法设置response的header信息：
response = Response()
response[‘Cache-Control‘] = ‘no-cache‘
Signature: .render()
和其他的 TemplateResponse 一样，调用该方法将response的序列化数据呈现为最终的response内容。 当 .render() 被调用时， response的内容将被设置成在 accepted_renderer实例上调用 .render(data, accepted_media_type, renderer_context) 方法返回的结果。
你通常并不需要自己调用 .render() ，因为它是由Django的标准响应周期来处理的
为了方便设置状态码，REST framewrok在rest_framework.status模块中提供了常用状态码常量。
HTTP_100_CONTINUE
HTTP_101_SWITCHING_PROTOCOLS
HTTP_200_OK
HTTP_201_CREATED
HTTP_202_ACCEPTED
HTTP_203_NON_AUTHORITATIVE_INFORMATION
HTTP_204_NO_CONTENT
HTTP_205_RESET_CONTENT
HTTP_206_PARTIAL_CONTENT
HTTP_207_MULTI_STATUS
HTTP_300_MULTIPLE_CHOICES
HTTP_301_MOVED_PERMANENTLY
HTTP_302_FOUND
HTTP_303_SEE_OTHER
HTTP_304_NOT_MODIFIED
HTTP_305_USE_PROXY
HTTP_306_RESERVED
HTTP_307_TEMPORARY_REDIRECT
HTTP_400_BAD_REQUEST
HTTP_401_UNAUTHORIZED
HTTP_402_PAYMENT_REQUIRED
HTTP_403_FORBIDDEN
HTTP_404_NOT_FOUND
HTTP_405_METHOD_NOT_ALLOWED
HTTP_406_NOT_ACCEPTABLE
HTTP_407_PROXY_AUTHENTICATION_REQUIRED
HTTP_408_REQUEST_TIMEOUT
HTTP_409_CONFLICT
HTTP_410_GONE
HTTP_411_LENGTH_REQUIRED
HTTP_412_PRECONDITION_FAILED
HTTP_413_REQUEST_ENTITY_TOO_LARGE
HTTP_414_REQUEST_URI_TOO_LONG
HTTP_415_UNSUPPORTED_MEDIA_TYPE
HTTP_416_REQUESTED_RANGE_NOT_SATISFIABLE
HTTP_417_EXPECTATION_FAILED
HTTP_422_UNPROCESSABLE_ENTITY
HTTP_423_LOCKED
HTTP_424_FAILED_DEPENDENCY
HTTP_428_PRECONDITION_REQUIRED
HTTP_429_TOO_MANY_REQUESTS
HTTP_431_REQUEST_HEADER_FIELDS_TOO_LARGE
HTTP_451_UNAVAILABLE_FOR_LEGAL_REASONS
HTTP_500_INTERNAL_SERVER_ERROR
HTTP_501_NOT_IMPLEMENTED
HTTP_502_BAD_GATEWAY
HTTP_503_SERVICE_UNAVAILABLE
HTTP_504_GATEWAY_TIMEOUT
HTTP_505_HTTP_VERSION_NOT_SUPPORTED
HTTP_507_INSUFFICIENT_STORAGE
HTTP_511_NETWORK_AUTHENTICATION_REQUIRED
原文：https://www.cnblogs.com/bbdbolg/p/14729934.html