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