공식문서를 직접 번역하고 공부한 글입니다!
If you're doing REST-based web service stuff... you should ignore
request.POST.
"
만약에 당신이 REST 기반의 웹 서비스를 하고있다면request.POST
는 반드시 무시해야한다.
REST Framework의 Request
클래스는 기존 HttpRequest
를 한층 확장해서 REST Framework의 유연한 파싱과 요청 인증을 지원해준다.
DRF의
Request
객체는 사용자가 요청들을 보통의form data
대하듯이 같은 방식으로 JSON 데이터와 다른 미디어 타입들을 대할 수 있도록 **유연한request 파싱
**을 제공해준다.
request.data
는 request body로 부터 parsed된(분석된) 컨텐츠를 리턴한다.
기존에 있던 request.POST
와 request.FILES
속성과 비슷하지만 아래점들이 다르다:
POST
가 아닌 HTTP 메소드의 컨텐츠 파싱을 지원한다.PUT
과 PATCH
요청의 컨텐츠를 접근할 수 있다.request.query_params
는 유의어인 request.GET
보다 더 정확한 이름이다.
REST Framework는 기존 장고의 request.GET
이 아닌 request.query_params
를 사용하기를 추천한다.
이런 컨벤션이 사용자의 코드베이스(소스 코드의 집합)이 더 정확하고 명확할 수 있도록 도와준다.
(이 것은 GET 요청 뿐만 아니라 query parameter를 포함하는 모든 HTTP 메소드 포함한다)
APIView
클래스나 @api_view
데코레이터가 뷰의 parser_classes
세트 기반이나, DEFAULT_PARSER_CLASSES
세팅을 기반으로 Parser
인스턴스들의 리스트로 속성이 자동적으로 세팅되도 보장한다.
보통 사용자가 이 속성에 접근할 필요는 없다.
Notes: 만약 클라이언트가 이상한 형태의 컨텐츠를 보낸 다음 request.data
에 접근하려 한다면, ParseError
를 일으킬 가능성이 생긴다. DRF에서는 APIView
클래스나 @api_view
데코레이터가 이 에러를 잡아주고 400 Bad Request
응답을 리턴하도록 기본적으로 설정이 되어있다.
만약 클라이언트가 파싱할 수 없는 컨텐츠 타입의 요청을 보낸다면 UnsupportedMediaType
에러를 일으킬 것이다. 그리고 이 에러는 415 Unsupported Media Type
응답을 리턴한다.
request는 사용자가 컨텐츠 협상 단계의 결과를 결정할 수 있도록 해주는 몇 가지 속성을 제공한다.
이를 통해서, 사용자가 다른 미디어 타입들을 위한 다른 직렬화 스키마들을 고르는 행동 같은 것을 실행할 수 있도록 해준다.
컨텐츠 협상 단계의 의해 선택된 인스턴스 제공자이다.
컨텐츠 협상 단계의 의해 통과된 미디어 타입을 대표하는 문자열이다.
REST Framework는 아래의 기능을 실행할 수 있는 유연하고, 매 request 마다의 인증을 제공한다:
request.user
는 행동이 사용되는 인증 규정에 좌지우지 되어도 django.contrib.auth.models.User
의 인스턴스를 일반적으로 리턴한다.
만약 인증되지 않은 request가 있다면 request.user
가 django.contrib.auth.models.AnonymousUser
의 인스턴스가 된다.
request.auth
는 모든 추가 인증 컨텍스트를 리턴한다.
request.auth
의 정확한 행동은 사용되는 인증 규정에 달려있지만, 대개 인증 된 토큰의 인스턴스일 수도 있다.
만약 request가 인증되지 않았다거나 추가 컨텍스트가 없다면, request.auth
의 기본 값은 None
이다.
APIView
클래스나 @api_view
데코레이터가 뷰의 authentication_classes
세트 기반이나, DEFAULT_AUTHENTICATORS
세팅을 기반으로 Authentication
인스턴스들의 리스트로 속성이 자동적으로 세팅되도 보장한다.
보통 사용자가 이 속성에 접근할 필요는 없다.
Notes: 사용자는 때때로 .user
나 .auth
속성들을 사용할때 WrappedAttributeError
가 발생하는 것을 볼 수도 있다. 이 에러들은 기본적인 AttributeError
로써 authenticator로 부터 발생한다.
하지만 외부 속성 접근으로부터 억눌리는 상황을 방지하기 위해 다른 예외 타입을 재발생시키는 것은 중요하다.
파이썬은 AttributeError
가 authenticator로 부터 발생했다는 것과 대신 request 객체가 .user
나 .auth
속성을 가지지 않는다는 가정을 할 것이라는 것을 알지 못한다.
이런 상황에서 authenticator는 고쳐질 필요가 있다.
REST Framework는
PUT
,PATCH
, 그리고DELETE
폼들 기반의 브라우저 같은 개선 사항들을 지원한다.
request.method
는 request의 HTTP 메소드를 나타내는 대문자로 된 문자열들을 리턴한다.
브라우저 기반의 PUT
,PATCH
와 DELETE
폼들을 명백히 지원한다.
request.content_type
은 HTTP request's body나 미디어 타입이 제공되지 않은 경우에 비어있는 문자열 문자열 객체를 리턴한다.
보통 사용자는 DRF의 기본 request 파싱 행동을 따르기 때문에 대게 사용자가 request의 컨텐츠 타입에 대한 직접적인 접근이 필요하지 않을 것이다.
만약 요청한 컨텐츠 타입에 대한 접근이 필요하지 않다면 사용자는request.META.get('HTTP_CONTENT_TYPE')
을 사용하기 보단 .content_type
속성을 사용해야한다.
.content_type
이 브라우저 기반의 non-form 컨텐츠를 확실히 지원해주기 때문이다.
request.stream
은 request 본문의 컨텐츠를 나타내는 스트림을 리턴한다.
보통 사용자는 REST Framework의 기본 request 파싱 행동을 따르기 때문에 대게 사용자가 request의 컨텐츠에 대한 직접적인 접근이 필요하지 않다.
REST Framework의
Request
는 장고의HttpRequest
의 연장이므로, 다른 모든 기존 속성들과 메소드들 또한 사용이 가능하다. 예를 들면,request.META
와request.session
딕셔너리들도 보통처럼 사용 가능하다.
구현적인 이유로 인해서 Request
클래스는 HttpRequest
클래스로부터 상속되지 않는다.
하지만 composition을 이용해서 클래스가 확장되니, 주의하자.