Request
아래 글은 장고 공식 문서를 한글로 번역한 글입니다. 시간을 들였으나 틀릴 가능성도 있으니 원문과 대조해서 읽으시길 권장드립니다.
만약 당신이 REST based 기반의 웹서비스를 만든다면 request.POST 잊어라
<Malcom Tredinnick, Django developers group>
DRF 진영의 Request 객체는 HttpRequest 객체를 component로 사용한다. DRF를 통한 API 요청이 왔을 때 요청에 대한 parsing과 관련해서 Request 객체는 이를 보조하고 인가 인증과 관련해 해서도 관련 기능을 제공한다. (Composite, component 관련 개념이 궁금하신 분은 맨 하단을 참고하세요)
Request parsing
DRF의 Request 객체는 HTTP Method의 여러 요청에 대해 parsing한 결과 값을 제공해준다. 그래서 사용자는 JSON 형태의 데이터와 다른 미디어타입과 관련한 데이터를 form 데이터 처리하 는 것과 유사한 방식으로 처리할 수 있다.
parser
컴파일러의 일부로 간주할 수 있다. 그 이유는 컴파일 또는 인터프리트 순간 코드를 읽고 문장을 분석해서 유의미한 결과 값을 도출하기 때문이다. 해당 행위를 parsing이라고 하고 해당 행위의 주체가 parser 이다.
.data
request.data 는 request body 의 파싱한 내용을 리턴한다. 반환 값은 request.POST 그리고 request.FILES 이 반환하는 것과 비교했을 때 다음의 부분을 부가적으로 갖고 있다.
모든 파싱된 데이터를 담고 있다. 해당 내용에는 입력 값으로파일과파일이 아닌 것도 포함한다.- HTTP method 중
POST이외의 메서드(PUT,PATCH)에 대한 요청에 대해서도 파싱을 하여파싱한 내용을 반환한다. - 폼 데이터에 입력된 데이터를 처리하는 것을 보조하는 개념이 아닌
DRF 로 설계한 API요청이 들어왔을 경우 이를 유연하게 처리하여유의미한 정보를 제공해준다. 예를 들어form data를 처리한 것 처럼 들어오는JSON data를 처리한다.
.query_params
request.query_params 은 request.GET의 보다 명확한 네이밍이다.
코드를 보다 명확하게 하기 위해 장고의 표준적인 request.GET 보다 request.query_params 를 사용하는 것을 추천한다. 이렇게 사용하는 것이 코드를 정확하고 명확하게 하는데 도움이 된다. 여러 유형의 HTTP 요청은 query parameters를 포함한다. request.GET만이 query parameter를 포함하지는 않는다.
.parsers
APIView 객체와 @api_view 데코레이터를 사용 할 경우 .parsers로 접근하는 메서드는 자동적으로 Parser 객체의 인스턴스가 담긴 리스트를 할당받는다. 객체 내부에서 parser_classes를 지정해주거나 DEFAULT_PARSER_CLASSES를 세팅해 줄 경우 지정 할 수 있다. 하지만 대개 해당 프로퍼티(메서드) 에 직접 접근 하는 경우는 드물다.
Note
만일 클라이언트 측에서 형태에 벗어난 내용을 보내게 된다면,request.data로 접근 할 경우ParseError를 발생시킨다. 기본적으로 장고 DRF에서 제공하는APIView객체 또는@api_view데코레이터는 에러를 잡아내400 Bad Requestresponse를 준다.
만일 클라이언트가 보낸 요청의 content-type(보내려는 데이터의 유형)이 parser가 parse할 수 없을 때에는 UnsupportedMediType 예외를 발생시킨다. 그리고 장고 앱은 415 Unsupported Media Type 으로 응답한다.
Authentication
Django DRF 관련 기능은 요청당 유연한 인증 기능을 제공한다. 그래서 아래와 같은 것을 처리 할 수 있게 한다.
- API 별로 다른 인증 정책을 적용할 수 있게 한다.
- API에 다수의 인증 정책을 적용할 수 있게 한다.
- 들어오는 요청과 관련한
user와token정보를 제공한다.
.user
객체 안에서 사용하고 있는 인증 정책에 따라 다르겠지만 request.user 는 보통django.contirb.auth.models.User의 인스턴스를 반환한다.
만약 인가과정을 거치지 않은 request의 경우 해당 프로퍼티는 django.contrib.auth.models.AnonymouUser의 인스턴스를 들고 있다.
자세한 정보는 링크를 참고하십시오.
.auth
request.auth 는 인증과 관련해서 추가적인 내용을 반환한다. request.auth 로의 접근은 현재 적용되고 있는 인증 정책에 의해 정해진다. 대개 인증된 요청과 관련한 토큰 인스턴스 를 반환한다.
만약 인증 처리가 필요 없는 요청의 경우 또는 인증과 관련해서 추가적인 내용이 제공되지 않은 경우 request.auth는 기본적으로 None값을 들고 있다.
자세한 정보는 링크를 참고하십시오.
.authenticators
APIView 객체와 @api_view 데코레이터로 API를 설계했을 때 request.authenticators 는 Authentication 객체 인스턴스 들을 모아놓은 배열을 값으로 갖고 있다. 이는 뷰 내부 authentication_classes에 클래스 변수의 할당이나 DEFAULT_AUTHENTICATORS의 세팅에 기반하여 request.authenticators는 값을 할당 받는다.
대개 해당 프로퍼티로의 접근을 하지 않을 가능성이 높다.
request.user또는request.auth로의 접근 시WrappedAttributeError를 마주할 수 있다. 해당 에러의 원인은authenticator프로퍼티에 기반한 표준적인AttributeError에 기반한다. 하지만 외부 프로퍼티(.user, .auth)로의 접근 했을 때 발생하는 에러는 표준적인 에러를 발생시키기 때문에 해당 에러가 발생 했을 경우 조금 더 디테일 하게 에러를 조정해 줄 필요성이 있다.
파이썬은 .authenticator로의 접근으로 인해 일어난 AttributeError를 인지하지 못 한다. 파이썬은 request의 객체가 .user 프로퍼티나 .auth 프로퍼티가 값을 갖고 있지 않다고 인식한다. .authenticator는 개선될 필요가 있다.
Browser enhancements
장고의 DRF 기능은 브라우저 기반의 PUT PATCH DELETE 폼과 관련해서 편의 기능을 제공한다.
.method
request.method 는 HTTP 요청 방식을 대문자 문자열로 반환한다. 브라우저 기반의 PUT PATCH DELETE 요청들이 이에 해당한다.
자세한 정보는 해당 링크를 참고하십시오
.content_type
request.content_type 프로퍼티는 HTTP 요청이 들어왔을 때 request body에 담은 미디어 타입을 표시해 주거나 미디어 타입이 제공되지 않았으르 경우 빈 문자열 을 반환한다.
request를 통해 바로 해당 프로퍼티로 접근 할 경우는 드물다. 대개 DRF request 객체를 많이 사용하기 때문이다.
만일 접근 할 일이 생긴다면 request.content_type 으로 접근 하는 것이 request.META.get('HTTP_CONTENT_TYPE) 으로 접근하는 것 보다 낫다. 폼 형태가 아닌 요청에 대한 내용 또한 담고 있기 때문이다.
자세한 정보는 해당 링크를 참고하십시오
.stream
request.stream 은 reqeust body에 대한 스트림에 대한 내용을 반환한다.
대개 해당 프로퍼티로 직접 접근 할 경우는 드물다. 대개 DRF의 request 객체에 더 많이 의존한다.
Standard HttpReqeust attributes
DRF의 Request 객체는 장고의 HTTPRequest의 인스턴스들을 들고있다. 그래서 HTTPRequest 에서 정의된 변수의 메서드 또한 접근 및 사용가능하다. 예를 들어 request.META 와 request.session 의 딕셔너리 자료구조 또한 이용 가능합다.
구현과 관련한 이유로 Request 객체는 HTTPRequest 객체를 상속받지 않습니다. 대신에
composite를 자처하여 해당 객체(HTTPRequest)의 인스턴스들을 들고있다.
Composition 은 OOP 디자인 관련 개념이다. 해당 개념 또한 객체와 객체와의 관계를 표시해준다. composite component 의 개념이 객체 관의 관계를 나타낸다. 전자는 component를 갖고 있고 후자는 composite에 속해 있다.
느슨한 결합으로 서로 영향을 미치는 바가 크지 않다.개인적인 의견이지만 예제와 사용 형태를 보았을 때 Composite 객체의 변수에 어느 객체의 인스턴스를 할당해서 사용하는 형태이며 평소에 사용하고 있지만 해당 개념을 의식하지 않고 사용 했을 가능성이 높다.
중간에 Content negotiation 부문은 해석을 진행하지 않았습니다.
