Добавление REST в Django

У меня есть приложение Django, которое прекрасно работает. Я добавляю службы REST. Я ищу дополнительный вклад в мою стратегию REST.

Вот несколько примеров того, над чем я заламываю руки.

  • Прямо сейчас я использую Django-REST API с кучей патчей.
  • Я думаю вернуться к простому написанию функций просмотра в Django, которые возвращают результаты JSON.
  • Я также вижу фильтрацию запросов REST в Apache и их маршрутизацию на отдельный экземпляр сервера, отличного от Django.

Пожалуйста, укажите один подход для каждого ответа, чтобы мы могли проголосовать за или против.


python django rest apache
person S.Lott    schedule 21.11.2008    source источник

Ответы (11)


arrow_upward
59
arrow_downward

Я думаю вернуться к простому написанию функций просмотра в Django, которые возвращают результаты JSON.

  • Явный
  • Переносимость на другие фреймворки
  • Не требует исправления Django
person Ali Afshar    schedule 21.11.2008
comment
Это может дать вам определенное расстояние, но если вы хотите выполнить аутентификацию, пожалуйста, не изобретайте велосипед — так мы получим множество небезопасных веб-приложений по всей сети. Вот почему мы все любим модуль аутентификации Django (мы любим? Не так ли...). Хорошая статья с дополнительными пояснениями заканчивается словами Я вас умоляю следовать чужому примеру и не внедрять собственную схему аутентификации.. - person Hamish Downer; 26.05.2011
comment
В этой статье есть несколько действительно хороших частей, но утверждение автора о том, что ключи API должны быть добавлены в URL-адрес, ошибочно и не соответствует RESTful. Вот для чего нужны заголовки WWW-Authenticate и Authorization. (См. комментарии Майка Амундсена и Рона Уэйла для более полного объяснения) - person Tom Christie; 01.06.2011
comment
Хотя я согласен с мнением на 100%, отсутствие RESTful не обязательно означает плохое. Хотя очевидно, что коды авторизации в URL-адресах — это, конечно, не хорошо. - person Ali Afshar; 12.01.2013

arrow_upward
30
arrow_downward

Обратите внимание, что REST означает не только результаты JSON. По сути, REST означает предоставление ориентированного на ресурсы API поверх собственного, но полноценного HTTP. Я не эксперт по REST, но вот несколько вещей, которые делает Rails.

  • URL-адреса должны быть хорошими, простые имена для ресурсов
  • Use the right HTTP methods
    • HEAD, GET, POST, PUT, and DELETE
    • Необязательно с переопределением (параметр формы «_method» переопределяет метод HTTP-запроса)
  • Support content-type negotiation via Accept request-header
    • Optionally with an override (filename extension in the URL will override MIME-type in the Accept request-header)
    • Доступные типы контента должны включать XML, XHTML, HTML, JSON, YAML и многие другие по мере необходимости.

Например, чтобы запустить встроенную поддержку HTTP, сервер должен отвечать на

GET /account/profile HTTP/1.1
Host: example.com
Accept: application/json

как он будет реагировать на

GET /account/profile.json HTTP/1.1
Host: example.com

И он должен реагировать на

PUT /account/profile HTTP/1.1
Host: example.com

var=value

как он будет реагировать на

POST /account/profile HTTP/1.1
Host: example.com

_method=PUT&var=value
person yfeldblum    schedule 02.10.2009
comment
Обратите внимание, что вы тоже не описываете отдых во всей его красе. Вы описываете уровень 2 модели зрелости. martinfowler.com/articles/richardsonMaturityModel.html - person nickik; 06.08.2013

arrow_upward
25
arrow_downward

Всем, кто ищет очень приличное подключаемое API-приложение для Django, обязательно ознакомьтесь с django от jespern. -piston, который используется внутри BitBucket.

Он хорошо поддерживается, имеет большое количество поклонников и несколько отличных ответвлений, которые делают такие вещи, как добавление поддержки нумерации страниц и других методов аутентификации (OAuth поддерживается из коробки).

Обновлено, чтобы отразить, что django-piston больше не поддерживается.

person oliland    schedule 29.03.2010
comment
Джанго-поршень уже нельзя считать благоустроенным. Хотя код был стабильным, когда он был более или менее заброшен, он все больше и больше устаревает по мере того, как django (и сообщество) движется вперед. Во-первых, существует множество нерешенных отчетов об ошибках. Поршень мертв, да здравствует django-tastypie и django-rest-framework. pydanny.com/choosing-an-api-framework-for-django. html - person B Robster; 17.05.2012

arrow_upward
7
arrow_downward

Tastypie — это также новый фреймворк REST для Django. У него такое же мышление, как у поршней, и он удаляет много шаблонного кода.

person RickyA    schedule 05.12.2011
comment
Попробовал, выглядит хорошо. - person Alex Ciminian; 28.12.2011
comment
Это уже не ново, и это актуально. Наряду с django-rest-framework. . . у обоих много поклонников, и они кажутся зрелыми. - person B Robster; 17.05.2012

arrow_upward
5
arrow_downward

Мой ответ на тот же вопрос здесь: Framework для реализации REST веб-сервис в Django

Краткая версия: посмотрите на https://github.com/jgorset/django-respite/ фреймворк REST на заре своего существования, но мы используем его каждый день в клиентских проектах.

person espenhogbakk    schedule 06.07.2011

arrow_upward
4
arrow_downward

Откажитесь от Django REST API и придумайте свой собственный проект с открытым исходным кодом, в который могут внести свой вклад другие. Я был бы готов внести свой вклад. У меня есть код, основанный на API-интерфейсах форм для выполнения REST.

person Sam Corder    schedule 21.11.2008

arrow_upward
3
arrow_downward

Я думаю вернуться к простому написанию функций просмотра в Django, которые возвращают результаты JSON.

Я бы согласился с этим ..
Али А подытожил это довольно хорошо.

Главное для меня — быть явным. Я бы не стал использовать функцию, которая автоматически преобразует объект в json, что, если объект имеет ссылку на пользователя и каким-то образом пароль (даже если он хеширован) попадает в фрагмент json?

person hasen    schedule 23.11.2008

arrow_upward
2
arrow_downward

В итоге я выбрал свою собственную REST API-инфраструктуру для Django (от которой я бы хотел избавиться, если найду работающую альтернативу), с несколькими пользовательскими представлениями, добавленными для крайних случаев, с которыми я не хотел иметь дело. Получилось нормально.

Итак, комбинация 1 и 2; без какой-либо структуры вы в конечном итоге будете писать один и тот же шаблон для общих случаев.

Я также сделал несколько автономных API. Мне нравится иметь их как автономные службы, но сам факт того, что они отделены от остального кода, приводит к тому, что ими пренебрегают. Нет технической причины; просто вне поля зрения, вне ума.

Что мне действительно хотелось бы видеть, так это подход, объединяющий формы Django и REST API, поскольку они часто имеют много общей логики. Концептуально, если ваше приложение предоставляет что-то в HTML, оно, вероятно, также захочет сделать это программно.

person Parand    schedule 23.11.2008

arrow_upward
2
arrow_downward

Вы можете взглянуть на django-dynamicresponse, который представляет собой облегченную структуру для добавления REST API с JSON в ваши приложения Django.

Для добавления поддержки API в существующие приложения Django требуются минимальные изменения, а также упрощается встраивание API с самого начала в новые проекты.

По сути, он включает в себя поддержку промежуточного программного обеспечения для синтаксического анализа JSON в request.POST, в дополнение к сериализации возвращаемого контекста в JSON или условной визуализации шаблона/перенаправления на основе типа запроса.

person chrismi    schedule 21.10.2010

arrow_upward
1
arrow_downward

вы можете попробовать создать универсальные функции, обрабатывающие данные (например, упомянутые parand), которые вы можете вызывать из представлений, генерирующих веб-страницы, а также те, которые генерируют json/xml/независимо

person Jiaaro    schedule 10.04.2009

arrow_upward
1
arrow_downward

TastyPie выглядит довольно интересно и многообещающе. Это хорошо сочетается с Джанго.

person Cody    schedule 27.01.2012