기존 HttpResponse 체와는 다르게, TemplateResponse 객체는 응답을 계산하기 위한 뷰로부터 제공된 컨텍스트의 세부정보를 유지한다. Response의 최종 출력은 응답 과정에서 필요한 시점까지 계산되지 않는다.

<aside> 💡 REST Framework는 클라이언트의 요청에 따라 사용자가 다수의 컨텐츠 형식으로 렌더링 할 수 있는 컨텐츠를 리턴할 수 있는**Response 클래스를 제공함으로써 HTTP 컨텐츠 협상을 지원**한다.

</aside>

Response 클래스는 Django의 SimpleTemplateResponse를 하위클래스로 가진다. Response 객체는 순수 기본 파이썬으로 구성된 데이터로 초기화된다. REST Framework는 어떻게 최종 응답 컨텐츠를 렌더링해야 할지 결정하기 위해 표준 HTTP 컨텐츠 협정을 사용한다.

사실 꼭 Response 클래스를 사용해야하는 것은 아니다. 사용자의 view에서 기존의 HttpResponse나 StreamingHttpResponse 객체가 필요하다면 사용해도 무관하다. 하지만 Response 클래스를 사용함으로써 컨텐츠 협상이된, 여러 포맷으로 렌더링 될 수 있는 WEB API Response을 위한 더 훌륭한 인터페이스를 제공한다.

만약 사용자가 어떤 이유로 REST Framework를 과하게 커스터마이즈하지 않는다면, 사용자는 항상 view가 Response객체를 리턴하도록 APIView 클래스나 @api_view 함수를 사용해야만 한다. 이렇게 함으로써, 객체가 view에서 리턴되기 전에, view는 컨텐츠 협정과 응답을 위한 적절한 renderer를 선택하는 작업을 수행할 수 있게 된다.

Creating Responses

Responses()

Signature: Response(data, status=None, template_name=None, headers=None, content_type=None)

기존 HttpResponse객체와는 다르게, 사용자는 렌더링된 콘텐츠로 Response 객체를 인스턴스화 하지 못한다. 대신에 사용자는 렌더링 되지 않은 기존 파이썬으로 구성된 데이터를 전달할 수 있다.

Response 클래스로 사용된 renderer들은 장고 모델 인스턴스들 같은 복잡한 데이터타입들을 원초적으로 다룰 수 없다. 그래서 사용자는 데이터를 Response 객체가 생성되기 전에 기본형의 데이터 타입들로 직렬화 해야 할 필요가 있다.

사용자는 데이터 직렬화를 수행하기 위해 REST Framework의 Serializer 클래스를 사용하거나 자신의 커스텀 serialization을 사용할 수 있다.

인자 목록(arguments):

• data: 응답을 위해 직렬화 된 데이터이다.
• status: 응답을 위한 상태 코드이다. 200이 기본 값이다.
• template_name: HTMLRender가 선택되었을 때 사용하는 템플릿 이름이다.
• headers: 응답에 사용되는 HTTP headers의 딕셔너리이다.
• content_type: 응답의 컨텐츠 타입이다. 전형적으로, 컨텐츠 타입은 컨텐츠 협정에 의해 결정된 렌더러로부터 자동적으로 세팅된다. 하지만 사용자가 명확하게 컨텐츠 타입을 구체화해야 하는 상황들도 있을 수 있다.

Attributes