# documentação Django 4.0.8.dev20220803071047

# “Decorators” para “view”

O Djanfo fornece muitos “decorators” que podem ser aplicados em “views” para suportar várias características HTTP.

See Decorating the class for how to use these decorators with class-based views.

## Métodos HTTP permitidos

Os “decorators” em `django.views.decorators.http` podem ser usados para restringir acesso a “views” baseado no método de requisição . Estes “decorators” retornarão uma `django.http.HttpResponseNotAllowed` se a condição não for atendida.

`require_http_methods`(request_method_list)

  “Decorator” que requer que uma “view” aceite somente alguns métodos de requisição em particular. Uso:

      from django.views.decorators.http import require_http_methods

      @require_http_methods(["GET", "POST"])
      def my_view(request):
          # I can assume now that only GET or POST requests make it this far
          # ...
          pass

  Note que o método de requisição deve estar em maiúsculas.

`require_GET`()

  “Decorator” que requer que a “view” somente aceite o método GET.

`require_POST`()

  “Decorator” que requer que a “view” somente aceite o método POST.

`require_safe`()

  “Decorator” que requer que a “view” somente aceite os métodos GET e HEAD. Estes métodos são geralmente considerados “seguros” porque eles não tem a importância de tomar uma ação além de retornar o conteúdo requisitado.

  Nota

  Web servers should automatically strip the content of responses to HEAD requests while leaving the headers unchanged, so you may handle HEAD requests exactly like GET requests in your views. Since some software, such as link checkers, rely on HEAD requests, you might prefer using `require_safe` instead of `require_GET`.

## Processamento condicional de “view”

Os seguintes “decorators” em `django.views.decorators.http` podem ser usados para controlar o comprtamento do “cache” em algumas “views” em particular.

`condition`(etag_func=None, last_modified_func=None)

`etag`(etag_func)

`last_modified`(last_modified_func)

  Estes “decorators” podem ser usados para gerar `ETag` e cabeçalhos `Last-Modified`; veja processamento condicional de “view”.

## Compressão GZip

Os “decorators” em `django.views.decorators.gzip` controlam a compressão de conteúdo baseados em cada “view”.

`gzip_page`()

  O “decorator” comprime o conteúdo se o navegador permitir compressão “gzip”. Ele define o cabeçalho `Vary` de acordo, então aquel cache irá basea seu armazenamento no cabeçalho `Accept-Encoding`.

## Variação de cabeçalhos

Os “decorators” em `django.views.decorators.vary` podem ser usados para controlar o “cacheamento” baseado em cabeçalhos específicos de requisições.

`vary_on_cookie`(func)

`vary_on_headers`(*headers)

  O cabeçalho `Vary` define quais cabeçalhos de requisições um mecânismo de “cache” deve levar em consideração ao construir sua chave de “cache”.

  Veja usando cabeçalhos “vary”.

## “Caching” – cacheando

Os “decorators” em `django.views.decorators.cache` controlam o “cacheamento” do lado do servidor e do cliente.

`cache_control`(**kwargs)

  This decorator patches the response’s `Cache-Control` header by adding all of the keyword arguments to it. See `patch_cache_control()` for the details of the transformation.

`never_cache`(view_func)

  This decorator adds an `Expires` header to the current date/time.

  This decorator adds a `Cache-Control: max-age=0, no-cache, no-store, must-revalidate, private` header to a response to indicate that a page should never be cached.

  Each header is only added if it isn’t already set.

## Common

New in Django 3.2.

The decorators in `django.views.decorators.common` allow per-view customization of `CommonMiddleware` behavior.

`no_append_slash`()

  This decorator allows individual views to be excluded from `APPEND_SLASH` URL normalization.