Django-rest-framework: etag를 쉽게 추가/검증합니다.

자, 예비 패치가 있습니다: https://github.com/schinckel/django-rest-framework/commit/cc3a88edc6be21347a9b35929d158b8831ba9bd3

그러나 이것에 대한 피드백에 대해 매우 기쁘게 생각합니다.

좋아, 처음에 내가 쓴 것은 이것이었다....

멋지네요. 정말 보고 싶습니다.

Coupla 생각 - 현재 가지고 있는 View._ETAG가 아닌 View.add_header를 사용할 수 있어야 합니다.
(그리고 .add_header가 ResponseMixin 클래스로 옮겨져야 할 것 같습니다.)

둘째, @condition , @etag 및 @last_modified 장식이 https://github.com/django/django/blob/master/django/views/decorators 의 직접적인 복제가 될 수 있기를

하지만 조금 더 자세히 살펴보니...

그리고 아마도 이것은 결국 올바른 방법이 아닐 것입니다...

REST 프레임워크 보기에서 실제로 HttpResponses를 반환할 수 있지만 일반적인 콘텐츠 협상/직렬화 항목이 모두 적용되지는 않습니다. @last_modified , @etag 및 @condition 데코레이터는 빈 HttpResponses만 반환하므로 실제로 문제가 되지는 않습니다.

그래서 내가 생각하는 것은 단순히 __setitem__ __getitem__ 및 has_header 를 Response 클래스에 추가하면 Django의 기존 @last_modified 라고 생각합니다. @etag 및 @condition 뷰가 사용 as_ 장식이 _so 오래 REST 프레임 워크보기에 잘 작동합니다 return Response(status, data) 오히려보다는 스타일 return data 스타일을.

Obv 그것을 문서화하면 도움이 될 것이지만 Django가 이미 수행하는 것을 복제하는 것보다 더 합리적일 수 있습니다.

어떻게 생각해?

django 데코레이터를 사용하는 데 한 가지 문제가 있을 수 있습니다. 메서드와 함께 작동하는지 확신할 수 없고 베어 기능만 사용할 수 있습니다. 내가 작성한 데코레이터는 이 경우에만 StackOverflow를 통해 찾은 데코레이터를 기반으로 했습니다.

그렇지 않을 수도 있습니다. 이 경우 이 솔루션이 더 나은 것 같습니다.

그렇긴 하지만, 덜 상용구이기 때문에 반환 데이터 스타일을 반환하고 있으며 일반적으로 json으로 직렬화하려는 개체만 반환합니다. 우리는 두 가지 방법으로 작동하도록 할 수 있습니다.

또 다른 옵션은 이를 View 클래스에 추가하는 믹스인일 수 있습니다.

또한 django 데코레이터가 조건부 PUT, POST 및 DELETE 요청과 관련하여 올바른 작업을 수행하지 않을 수도 있습니다. 이 문제를 해결하기 위해 sinatra에 패치를 제출했습니다.

마지막 비트를 무시하십시오. 분명히 저는 코드를 제대로 읽지 않았습니다.

실제로 요점이 있습니다. 이러한 데코레이터는 _methods_에서 ATM을 작동하지 않을 수 있습니다. 추가 'self' 인수가 있기 때문입니다. 나는 그것을 조사하고 poss가 Django에 티켓을 제출할 것입니다. Django도 CBV와 함께 작업해야 하기 때문입니다...

아, 알겠습니다. 이제 https://docs.djangoproject.com/en/dev/topics/class-based-views/#decorating -class-based-views
그래서 이것을 닫으려면 다음이 필요하다고 생각합니다.

1. 응답에 대한 약간의 조정
2. 약간의 가벼운 문서

분명히 그 문서를 보았지만 그 데코레이터를 보지 못했습니다!

나는 django 데코레이터를 사용하려고 했고 초기 결과는 정말 이상했고, 관련 없는 etag 함수에 나타나는 뷰에만 속해야 하는 정보가 있었습니다.

그것을 조금 더 좋게 만들기 위해 몇 시간 동안 노력한 후, 나는 내 문제를 해결하고 충분히 일반적으로 보이는 솔루션을 생각해 냈습니다. 이에 대해 어떻게 생각하십니까?

https://bitbucket.org/vitormazzi/django-rest-framework/changeset/6f8de4500c6f

2.x 릴리스가 나온 지금 이 문제에 새로운 생명을 불어넣기를 바랍니다.

여기에서 내 생각은 대부분 프로젝트에 기능을 추가하려고 시도하고 이 게시물 을 읽는 것에서 비롯된 것입니다.

DRF가 ETag를 고려해야 하는 두 가지 영역, 즉 뷰에서의 사용과 인스턴스 버전의 고유한 표현을 얻는 방법이 있습니다.

견해

가져 오기
GET 요청은 적절한 헤더에서 개체 ETag를 제공하기만 하면 됩니다. RetrieveModelMixin 대한 한 줄 변경은 다음을 쉽게 추가할 수 있습니다.

def retrieve(self, request, *args, **kwargs):
    self.object = self.get_object()
    serializer = self.get_serializer(self.object)
    headers = {'ETag': self.object.etag}
    return Response(serializer.data, headers=headers)

넣기, 패치, 삭제
HTTP 동사 업데이트에 대한 일반적인 확인은 보기의 dispatch 하거나 ETag가 켜져 있는지 확인해야 하므로 다른 메서드로 가져올 수 있습니다(아래 옵션 섹션 참조).

    header_etag = request.META.get('HTTP_IF_MATCH')
    if header_etag is None:
        return Response({'error': 'IF_MATCH header is required'}, status=400)

그런 다음 개체를 검색한 후 요청이 올바른 개체를 보고 있다고 생각하는지 확인하기 위해 더 자세히 확인합니다.

    if self.object.etag != header_etag:
        return Response({'error': 'object has been updated since you last saw it'}, status=412)

인스턴스 버전의 고유한 표현

나는 객체의 ETag의 실제 생성이 DRF의 문제가 되어야 한다고 생각하지 않습니다. 내 개체의 updated 필드의 에포크 시간을 사용하여 테스트했지만 더 복잡해야 함을 쉽게 알 수 있었습니다.

저는 DRF가 기본적으로 obj.etag 를 조회하지만 get_etag() 및 etag_var = 'get_my_objects_etag' 와 같은 일반 CBV 흐름을 사용하여 구성할 수 있다고 제안합니다.

헤더와 비교하고 유형을 해석하려는 시도는 기껏해야 고통스러울 것이기 때문에 ETag가 객체에서 문자열로 검색되도록 강제해야 합니다.

옵션

• ETag 사용을 켜거나 끄기 위한 전역 설정(직렬 변환기 등).
• 보기에 대한 두 가지 설정:
  
  
  
  • use_etags (또는 이와 유사한 것) - 부울
  
  
  • etag_var - 해당 객체에 대해 getattr 할 수 있는 함수 이름 문자열
  
  

@ghickman - ETag 및 LastModified를 결정하는 동작이 다른 플러그형 클래스와 유사하게 보이는지 확인하고 싶습니다. 즉. 다음과 같은 것이 있습니다.

class MyView(views.APIView):
    cache_lookup_classes = []

캐싱 서명은 ETag와 LastModified를 모두 처리해야 하며 우리가 제공하고자 하는 두 가지가 있습니다.

• 지정된 객체 인스턴스에서 etag 및/또는 마지막으로 수정된 사항을 결정합니다.
• 들어오는 요청에 따라 etag 및/또는 마지막 수정을 선제적으로 결정합니다.

BaseCacheLookup 있고 다음과 같은 두 가지 메서드 서명이 있습니다.

.object_etag_and_last_modified(self, view, obj)
.preemptive_etag_and_last_modified(self, view, request, *view_kwargs, **view_kwargs)

객체가 (etag, last modified) 의 2-튜플을 반환하면 둘 중 하나는 단순히 없음일 수 있습니다.
들어오는 요청에 일치하는 If-Modified-Since 또는 If-None-Match 헤더가 포함된 경우 304 Not Modified 응답이 반환됩니다. 들어오는 응답에 일치하는 If-Match 또는 If-Unmodified-Since가 포함되어 있으면 412 Precondition Failed 응답이 반환됩니다.

이렇게 하면 설명한 구현과 일치하는 CacheLookupClass뿐만 아니라 다른 변형도 허용됩니다.

예를 들어, 다른 마지막 수정 세분성에서 여러 캐시 조회 클래스를 적용할 수도 있습니다.
GlobalLastModifiedLookup 외에 ObjectETagLookup 합니다. 그러면 캐시된 복사본 이후에 쓰기가 수행되지 않은 경우 데이터베이스 호출을 수행하기 전에 뷰가 선제적으로 반환될 수 있습니다. (Varnish와 함께 서버 측 캐싱을 사용하는 경우 이와 같은 정말 기본적인 정책이라도 엄청난 차이를 만들 수 있습니다)

이 플러그인의 클래스 측면이 합리적으로 들립니까?

현재 구현에서 사용하지 않기 때문에 LastModified에 대해 생각하지 않았지만 주어진 목적을 감안할 때 포함하는 것이 합리적입니다.

Pluggable 클래스는 특히 LastModified 및 ETag 구현을 기본 예제로 포함하는 경우 좋은 아이디어처럼 들립니다. 나는 GET 캐싱이 프로젝트에 대한 최소한의 변경으로 매우 쉽게 켤 수 있다는 아이디어를 좋아합니다.

나는 etag와 last_modified 생성을 당신이 제안한 대로 구현되지 않을 때 None 반환하는 두 가지 방법(그 이름 중)으로 분할하는 것을 선호합니다. 그런 다음 CacheLookup 백엔드는 하나 및/또는 다른 하나를 구현하도록 선택할 수 있습니다. 유용하다고 생각되면 두 가지를 결합한 편리한 유틸리티 메서드( cachable_obj_repr 또는 unique_obj_repr 아마도?)를 항상 제공할 수 있습니다.

tl;dr 예, 플러그형 클래스 측면은 합리적으로 들리고 훨씬 더 큰 유연성을 제공해야 합니다. 이에 대한 패치 작성을 시작하게 되어 기쁩니다.

여러분, 안녕하세요. 관심이 있으시면 내 확장 라이브러리 http://chibisov.github.io/drf-extensions/docs/ 에서 etag 지원에 대한 다른 접근 방식을 구현했습니다

@chibisov Neato. #1019를 끝내야 하므로 문서 어딘가에 이와 같은 패키지에 연결할 수 있습니다.

#1019로 닫고 @chibisov 의 패키지가 나열됩니다.

이것은 우리가 어느 시점에서 이것에 대한 공식적인 지침을 제공하기를 원하기 때문에 의도적으로 3.3으로 이정표가 찍혔습니다. 우리가 이것을 닫힌 상태로 두기로 선택하더라도 크게 걱정하지 않지만 내 내부 로드맵에 있습니다.

불행히도 drf-extensions의 Etag 기능에 대한 기본 구현 및 문서는 단순히 잘못되었으며 위험한 버그가 있습니다. _response_가 변경되는 것이 아니라 _request_가 변경되면 Etag를 변경합니다. 서버 측 캐싱에 대해 원하는 것이 정확히 무엇이며 Etag에 대해서는 원하지 않는 것입니다.

@mbox 가장 좋은 방법은 drf-extensions에서 이에 대한 문제를 여는 것입니다. 또는 여기에서 DRF "핵심" 문제가 열려 있다고 생각하는 경우입니다. 테스트에 실패하면 문제를 살펴보는 데 좋은 출발점이 될 것입니다.

@mbox @xordoquy
방금 DRF API를 통해 리소스를 조작하기 위한 낙관적 동시성 제어를 허용하는 drf-extensions(https://github.com/chibisov/drf-extensions/pull/171)에 PR을 제출했습니다. 모든 개체 필드의 시맨틱 해시를 사용하고 있으며 데모 목적으로 테스트 앱을 포함했습니다. Python 2.7, 3.4, 3.5에서 DRF>=3.3.1 및 django>=1.8에 대해 테스트되었습니다.

감사

미래의 독자를 위한 참고 사항 - DRF와 함께 Django의 조건부 데코레이터를 사용하기 위해 작은 패키지를 만들었습니다. 따라서 관심이 있는 경우:
https://github.com/jozo/django-rest-framework-condition