---
title: "“Decorators” para “view”"
version: 1.9
locale: pt-br
source: https://docs.djangoproject.com/pt-br/1.9/topics/http/decorators/
canonical: https://djangodocs.dev/pt-br/1.9/topics/http/decorators/
---
# “Decorators” para “view”

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

## Métodos HTTP permitidos

Os “decorators” em [`django.views.decorators.http`](#module-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`](/pt-br/1.9/ref/request-response/#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.

> **Note**
>
> O Django irá tirar automaticamente o conteúdo de respostas de requisições HEAD enquanto deia o cabeçalho imutável, de modo que você pode nas suas “views” lidar com requisições HEAD exatamente da mesma maneira que lida com requisições GET. Já que alguns softwares, como checadores de links, dependem de requisições HEAD, você talvez prefira usar o `require_safe` ao invés do `require_GET`.

## Processamento condicional de “view”

Os seguintes “decorators” em [`django.views.decorators.http`](#module-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”](/pt-br/1.9/topics/conditional-view-processing/).

## Compressão GZip

Os “decorators” em [`django.views.decorators.gzip`](#module-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`](#module-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”](/pt-br/1.9/topics/cache/#using-vary-headers).

## “Caching” – cacheando

Os “decorators” em [`django.views.decorators.cache`](#module-django.views.decorators.cache) controlam o “cacheamento” do lado do servidor e do cliente.

#### `never_cache(view_func)`

O `decorator` adiciona um cabeçalho `Cache-Control: max-age=0, no-cache, no-store, must-revalidate` para que uma resposta indique que uma página nunca deve ser “cacheada”.

> **Changed in Django 1.9**
>
> Antes do Django 1.9, `Cache-Control: max-age=0` era enviado. Isso não preveni de forma confiável o “cahe” em todos os browsers.
