1. DRF-Requests

Requests

DRF는 Request클래스를 좀 더 표준적인 HttpRequest로 확장합니다. 이것을 통해 좀 더 유연하게 request parsing과 request authentication이 가능합니다.

Request Parsing

DRF에서 Request 객체는 일반적으로 양식 데이터를 처리하는 것과 동일한 방식으로 JSON 데이터 또는 다른 미디어 유형을 사용하여 요청을 처리할 수 있는 form-data를 제공해줍니다.

.data

request.data 는 request body에 파싱된 콘텐츠들을 반환해줍니다. 이것은 request.POST의 표준과 유사합니다. 그리고 request.FILES의 다음과 같은 속성을 제외합니다.

• 모든 파싱된 콘텐츠들은 파일과 파일이 아닌 입력을 포함합니다.
• Post 이외의 HTTP 메서드의 content 파싱을 지원하므로 PUT, PATCH 요청의 내용에 접근할 수 있습니다.
• DRF는 form-data만 지원하는게 아니라 프레임워크의 유연한 request 파싱을 지원합니다. 예를 들면 들어오는 JSON 데이터를 처리하는 방법과 유사하게 처리할 수 있습니다.

.query_params

request.query_params는 request.GET 보다 더 정확합니다.

코드를 명확하기위해 장고의 스탠다드인 request.GET 보다는 request.query_params를 사용해야합니다.

이렇게 하면 code base보다 더 정확하고 명확하게 유지할 수 있습니다. 모든 HTTP method 유형은 GET 요청뿐만 아니라 쿼리 파라미터를 포함할 수 있습니다.

.parsers

APIView 클래스 또는 @api_view 데코레이터는 view에 설정된 parser_classes 또는 DEFAULT_PARSER_CLASSES 설정에 따라 이 property가 자동으로 인스턴스 목록으로 설정되도록 합니다.

일반적으로는 이 속성에 접근할 필요는 없습니다.

 

참고 사항 : 만약 클라이언트가 잘못된 형식의 콘텐츠를 보내는 경우 request.data에 접근하면 ParseError가 발생할 수도 있습니다. DRF에서 APIView 클래스 또는 @api_view 데코레이터가 오류를 확인하고 400 bad request를 반환해줍니다.

클라이언트가 파싱할 수 없는 콘텐츠 타입(content-type)를 사용하여 request를 보내면 UnsupportedMediaType 예외가 발생하고 기본적으로 415 Unsupported Media Type를 반환해 줍니다.

Content negotiation

Content negotiation(콘텐츠 협상) 개념

HTTP에서, 컨텐츠 협상이란 동일한 URI에서 리소스의 서로 다른 버전을 서브하기 위해 사용되는 메커니즘으로, 사용자 에이전트가 사용자에게 제일 잘 맞는 것이 무엇인지(예를 들어, 문서의 언어, 이미지 포맷 혹은 컨텐츠 인코딩에 있어 어떤 것이 적절한지)를 명시할 수 있습니다.

request에는 콘텐츠 협상 단계의 결과를 결정할 수 있는 일부 속성이 표시됩니다. 이것을 통해 서로다른 미디어 유형에 대해 다른 serializer 구성표를 선택하는 등의 동작을 구현할 수 있습니다.

참고 링크 : https://developer.mozilla.org/ko/docs/Web/HTTP/Content_negotiation

Content negotiation - HTTP | MDN

.accepted_renderer

콘텐츠 협상 단계에서 선택한 renderer 인스턴스 입니다.

.accepted_media_type

콘텐츠 협상 단계에서 수락한 미디어 유형을 나타내는 문자열 입니다.

Authentication(인증)

DRF는 다음과 같은 기능을 통해 요청별 유연한 인증을 처리해 줍니다.

• API의 여러 부분에 대해 서로 다른 인증(Authentication) 정책을 사용합니다.
• 여러가지 인증 정책 사용을 지원합니다.
• 수신 요청과 연결된 사용자 및 토큰 정보를 모두 제공해줍니다.

.User

request.user 일반적으로 django.contrib.auth.models.User을 통해 인스턴스를 반환해주는데 사용중인 인증 정책에 따라 동작이 달라질 수 있습니다.

자세한 내용은 다음에 자세하게 설명하겠습니다.

.auth

request.auth 에서는 추가 인증 context를 반환합니다. request.auth 의 정확한 동작은 사용 중인 인증 정책에 따라 다르지만 일반적으로 요청이 인증되지 않은 토큰의 인스턴스 일 수 있습니다.

요청이 인증되지 않았거나 추가 context가 없는 경우 기본적인 request.auth는 None입니다.

.authenticators

APIView 클래스 또는 @api_view 데코레이터는 view에 설정된 Authentication_classes 또는 DEFAULT_AUTHENTICATORS 설정에 따라 이 property가 자동으로 Authentication 인스턴스 목록으로 설정되도록 합니다.

이 설정도 마찬가지로 접근할 필요가 없습니다.

 

참고 사항 : 여러분은 .user이나 .auth 속성(property)을 호출할 때 WrappedAttributeError 를 볼 수 있습니다. 이 에러들은 authenticator에서 표준 AttributeError 로 발생하지만 외부 속성 접근에 의해 이러한 오류가 억제되는 것을 방지하기 위해 다른 예외 타입으로 raise해야 합니다.

파이썬은 AttributeError 가 인증자에서 발생한다는 것을 인식하지 못하고 대신 요청 개체에 .user 또는 .auth 속성이 없다고 가정합니다. 그래서 authenticator을 수정해야 할 필요가 있습니다.

Browser enhancements

DRF는 브라우저 기반 PUT, PATCH 및 DELETE 양식과 같은 몇 가지 브러우저 향상 기능을 지원합니다.

.Method

request.method의 리턴값은 HTTP 요청의 대문자로 표현합니다.

브라우저 기반 PUT, PATCH 및 DELETE 양식이 투명하게 지원됩니다.

.content_type

request.content_type는 HTTP request body의 media type을 나타내는 string object 또는 media type 제공되지 않은 경우 빈 문자열을 반환합니다.

일반적으로 DRF의 기본적인 request parsing behavior에 의존하므로 일반적으로 request의 content-type에 직접 접근할 필요가 없습니다.

request의 content-type 유형에 접근해야 하는 경우 request를 사용하는 것 보다 .content_type속성을 먼저 사용해야 합니다. request.META.get('HTTP_CONTENT_TYPE')은 브라우저 기반의 non-form content를 투명하게 지원합니다.

.stream

request.stream은 request body의 content를 나타내는 stream을 리턴해줍니다.

일반적으로 DRF의 기본적인 content parsing behavior에 의존하므로 일반적으로 request의 content에 직접 액세스할 필요가 없습니다.

Standard HttpRequest attributes

DRF의 request가 Django의 HttpRequest를 확장함에 따라, 다른 모든 표준 특성 및 방법도 사용할 수 있습니다. 예를 들어, request.META와 request.session은 정상적으로 사용할 수 있습니다.

구현상의 이유로 Request 클래스는 HttpRequest 클래스에서 상속되지 않고, 대신 컴포지션을 사용하여 클래스를 확장합니다.

• 컴포지션 : 명시적 선언(포함)이라고도 합니다.

참고 링크 : https://www.django-rest-framework.org/api-guide/requests/#standard-httprequest-attributes

Requests - Django REST framework