Правильный способ инициализации внутренних данных для API в Django с помощью Piston/Django-tastypie vs jsonrpc

После некоторых реализаций API с использованием jsonrpclib в Python мне нужно перенести их в проект Django Framework. Я новичок в Django и Piston/tastypie, но имею некоторый опыт использования библиотек jsonrpc/xmlrpc в своих приложениях Python.

До сих пор я разработал несколько модулей с ServiceClass, прикрепленным к реестру сервера jsonrpc, который обрабатывает запрос и вызывает методы в ServiceClass.

Когда класс прикрепляется к реестру, создается новый экземпляр ServiceClass, загружающий все исходные данные и сохраняющий их в памяти, поэтому каждый метод, вызываемый через jsonrpc, может иметь доступ к внутренним значениям в этом экземпляре.

Теперь я пытаюсь сделать то же самое в Django с Piston или Tastypie. Я перешел по этой ссылке http://www.robertshady.com/content/creating-very-basic-api-using-python-django-and-piston и другие ресурсы, и вся прочитанная мной документация ясна и показывает правильный способ работы с ней:

  • Измените url.py, чтобы сопоставить запросы, такие как «/api/», с определенным обработчиком.
  • Добавьте handler.py в приложение API, расширяя BaseHandler Piston/Tastypie.

Поэтому мне интересно, правильный ли это способ работы с Django и API, чтобы создать экземпляр моего ServiceClass (инициировать данные, предоставить методы) внутри handler.py, когда я создаю экземпляр Handler, расширяющий BaseHandler. Этот класс Handler создается один раз при запуске сервера? Что, если мой ServiceClass полагается на какую-то модель для загрузки данных из нее?

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

Буду рад услышать любую рекомендацию, Спасибо,


django api django-piston tastypie
person Luchux    schedule 07.03.2012    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Специально для поршня... Вы действительно не должны использовать обработчик с точки зрения экземпляра. Это больше похоже на метакласс, который вы настраиваете с помощью атрибутов класса. Эти атрибуты определяют, к какой модели будет привязан обработчик. И какие поля он должен показывать или какие методы он поддерживает.

Как правило, запрос входит в один из ваших методов, а затем вы обрабатываете запрос, как хотите, как изолированное состояние. Если ему нужно использовать общий ресурс или использовать модель для запросов, эта часть зависит от вас, поскольку она используется совместно с каким-либо импортированным ресурсом. Вы сказали, что вам нужна модель, поэтому вы должны привязать ее к обработчику как атрибут класса, а затем запросить ее. Вы не должны хранить состояние в обработчике.

person jdi    schedule 07.03.2012
comment
Я понимаю. В любом случае, мне нужно сохранить состояние. Почему? ну, мое приложение — проверка орфографии, и я хочу реализовать API, с помощью которого пользователь может запросить предложение и получить исправленное. Внутри моего SpellChecker есть состояние (он обучен с помощью корпуса, имеет словарь слов и внутреннюю вероятностную модель, основанную на распределении слов). Я не могу загружать эту модель каждый раз, когда приходит запрос, только один раз при инициализации. Таким образом, нет никакой модели вообще, чтобы связать с. Возможно, решение состоит в том, чтобы вообще внедрить API вне Django Framework, но я хотел использовать нативное регулирование, аутентификацию и т. д. - person Luchux; 07.03.2012
comment
Легкий. Либо сделайте свой класс SpellChecker одноэлементным (en.wikipedia.org/wiki/Singleton_pattern), либо создайте экземпляр средства проверки орфографии на глобальном уровне вашего модуля обработчика и ссылайтесь на него в методах обработчика. Вот ссылка, показывающая, как сделать синглтон с помощью метакласса: stackoverflow.com/questions/31875/ - person jdi; 07.03.2012
comment
Кроме того, работа поршня и вкусных пирогов заключается в том, чтобы просто правильно отобразить запрос и направить его в ваши методы. Что вы делаете внутри этого, чтобы на самом деле построить свой ответ, зависит от вас. Поэтому я бы сказал, что это все еще подходящий путь для вас. - person jdi; 08.03.2012