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

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

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

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

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

Ответы

Ответ 1

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

Явное
Portable для других фреймворков
Не требует исправления Django

Ответ 2

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

URL-адреса должны быть хорошими, простыми именами для ресурсов
Использовать правильные HTTP-методы
- HEAD, GET, POST, PUT и DELETE
- Необязательно с переопределением (параметр формы '_method' переопределяет HTTP-запрос-метод)
Поддержка согласования типа контента с помощью Accept-header-заголовка
- Необязательно с переопределением (расширение имени файла в URL-адресе переопределяет MIME-тип в заголовке запроса Accept)
- Доступные типы контента должны включать 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

Ответ 3

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

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

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

Ответ 4

Tastypie также является новой структурой REST для Django. Он имеет такое же мышление, что и поршни, и удаляет много кодировки.

Ответ 5

Мой ответ на тот же вопрос: Рамки для реализации веб-службы REST в Django

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

Ответ 6

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

Ответ 7

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

Я бы пошел с этим..
Али А очень хорошо это обозначил.

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

Ответ 8

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

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

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

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

Ответ 9

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

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

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

Ответ 10

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

Ответ 11

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