реклама
Запросы и ответы в django-rest-framework. Я решил перевести официальное руководство. Оригинал страницы Tutorial 2: Requests and Responses. Углубляемся в ядро DRF.
Rest framework представляет объект Request, который расширяет обычный Http-запрос и обеспечивает более гибкий синтаксический анализ запроса. Основной функциональностью объекта Request является request.data, который аналогичен request.POST, но более полезен для работы с веб-API.
# Обрабатывает только данные формы.
# Работает только для метода "POST".
request.POST
# Обрабатывает произвольные данные.
# Работает для методов "POST", " PUT " и "PATCH".
request.data
Rest framework также вводит объект ответа, который является типом ответа шаблона, который принимает неупорядоченное содержимое и использует согласование содержимого для определения правильного типа содержимого для возврата клиенту. Вы можете поместить в Response свой словарь.
# Отображает тип содержимого по запросу клиента.
return Response(data)
Использование числовых кодов статуса HTTP в ваших представлениях не всегда делает очевидным чтение, и легко не заметить, если вы получите неправильный код ошибки. Rest framework предоставляет более явные идентификаторы для каждого кода состояния, например HTTP_400_BAD_REQUEST в модуле status. Это хорошая идея использовать их повсюду, а не использовать числовые идентификаторы.
Rest framework предоставляет две обёртки, которые можно использовать для записи представлений API.
Эти обёртки предоставляют некоторые функциональные возможности. Вы получите экземпляры Request в вашем представлении, и добавление контекста к объектам ответ так, что согласование содержания может быть выполнено.
Обертки также обеспечивают поведение такое как возврат 405 Method Not Allowed (не разрешенных ответов) когда это необходимо, и обработку любого исключения ParseError, которое возникает при доступе к request.data при переданных неправильных данных.
Хорошо, давайте начнем использовать эти новые компоненты, чтобы написать несколько представлений.
Нам не нужен наш класс JSONResponse в views.py больше, так что вперед и удалите это. Как только это будет сделано, мы можем выполнить рефакторинг наших представлений.
from rest_framework import status
from rest_framework.decorators import api_view
from rest_framework.response import Response
from snippets.models import Snippet
from snippets.serializers import SnippetSerializer
@api_view(['GET', 'POST'])
def snippet_list(request):
"""
List all code snippets, or create a new snippet.
"""
if request.method == 'GET':
snippets = Snippet.objects.all()
serializer = SnippetSerializer(snippets, many=True)
return Response(serializer.data)
elif request.method == 'POST':
serializer = SnippetSerializer(data=request.data)
if serializer.is_valid():
serializer.save()
return Response(serializer.data, status=status.HTTP_201_CREATED)
return Response(serializer.errors, status=status.HTTP_400_BAD_REQUEST)
Наше представление экземпляра является улучшением по сравнению с предыдущим примером. Это немного более лаконично, и код теперь очень похож на то, как если бы мы работали с API Forms. Мы также используем именованные коды статуса, что делает значения ответа более очевидными.
Вот представление для отдельного фрагмента, в views.py модуль.
@api_view(['GET', 'PUT', 'DELETE'])
def snippet_detail(request, pk):
"""
Retrieve, update or delete a code snippet.
"""
try:
snippet = Snippet.objects.get(pk=pk)
except Snippet.DoesNotExist:
return Response(status=status.HTTP_404_NOT_FOUND)
if request.method == 'GET':
serializer = SnippetSerializer(snippet)
return Response(serializer.data)
elif request.method == 'PUT':
serializer = SnippetSerializer(snippet, data=request.data)
if serializer.is_valid():
serializer.save()
return Response(serializer.data)
return Response(serializer.errors, status=status.HTTP_400_BAD_REQUEST)
elif request.method == 'DELETE':
snippet.delete()
return Response(status=status.HTTP_204_NO_CONTENT)
Все это должно быть очень знакомо - это не сильно отличается от работы с обычными представлениями Django.
Обратите внимание, что мы больше не связываем наши запросы или ответы с данным типом контента. request.data может обрабатывать входящие запросы json, но также может обрабатывать и другие форматы. Аналогично мы возвращаем объекты ответа с данными, но разрешаем Rest framework рендерить наш ответ в правильном типе для нас.
Чтобы воспользоваться тем, что наши ответы больше не привязаны к одному типу контента, давайте добавим поддержку суффиксов формата в наши конечные точки API. Использование суффиксов формата дает нам правила, которые явно ссылаются на данный формат, и означает, что наш API сможет обрабатывать URL-адреса, такие как http://example.com/api/items/4.json-
Начните с добавления в аргумент ключевого слова format в оба представления.
def snippet_list(request, format=None):
#и
def snippet_detail(request, pk, format=None):
Теперь обновите snippets/urls.py файл немного, чтобы добавить набор format_suffix_patterns в дополнение к существующим URL-адресам.
from django.urls import path
from rest_framework.urlpatterns import format_suffix_patterns
from snippets import views
urlpatterns = [
path('snippets/', views.snippet_list),
path('snippets/', views.snippet_detail),
]
urlpatterns = format_suffix_patterns(urlpatterns)
Нам не обязательно добавлять эти дополнительные шаблоны url, но это дает нам простой и чистый способ ссылки на определенный формат.
Продолжайте и протестируйте API из командной строки, как мы сделали в части 1 учебника. Все работает примерно так же, хотя у нас есть более приятная обработка ошибок, если мы отправляем недопустимые запросы.
Мы можем получить список всех фрагментов как и раньше.
http http://127.0.0.1:8000/snippets/
HTTP/1.1 200 OK
...
[
{
"id": 1,
"title": "",
"code": "foo = \"bar\"\n",
"linenos": false,
"language": "python",
"style": "friendly"
},
{
"id": 2,
"title": "",
"code": "print(\"hello, world\")\n",
"linenos": false,
"language": "python",
"style": "friendly"
}
]
Мы можем управлять форматом ответа, который мы получаем с помощью заголовка Accept в Header:
# Request JSON
http http://127.0.0.1:8000/snippets/ Accept:application/json
# Request HTML
http http://127.0.0.1:8000/snippets/ Accept:text/html
Или путем добавления суффикса формата:
# JSON suffix
http http://127.0.0.1:8000/snippets.json
# Browsable API suffix
http http://127.0.0.1:8000/snippets.api
Аналогично, мы можем управлять форматом запроса, который мы отправляем, используя заголовок Content-Type
# POST using form data
http --form POST http://127.0.0.1:8000/snippets/ code="print(123)"
{
"id": 3,
"title": "",
"code": "print(123)",
"linenos": false,
"language": "python",
"style": "friendly"
}
# POST using JSON
http --json POST http://127.0.0.1:8000/snippets/ code="print(456)"
{
"id": 4,
"title": "",
"code": "print(456)",
"linenos": false,
"language": "python",
"style": "friendly"
}
Если вы добавите переключатель --debug к http-запросам выше, вы сможете увидеть тип запроса в заголовках запросов. Теперь перейдите и откройте API в веб-браузере, посетив http://127.0.0.1:8000/snippets/.
Поскольку API выбирает тип содержимого ответа на основе запроса клиента, он по умолчанию возвращает HTML-форматированное представление ресурса, когда этот ресурс запрашивается веб-браузером. Это позволяет API возвращать полностью просматриваемое веб-представление HTML.
Наличие веб-просматриваемого API-это огромная победа в юзабилити и упрощает разработку и использование вашего API. Это также значительно снижает барьер для входа для других разработчиков, желающих проверить и работать с вашим API.
См. В разделе browsable api есть дополнительные сведения о функции API-интерфейса для просмотра и настройки его.