0

After some API implementations, using jsonrpclib in Python, I need to migrate them inside a Django Framework project. I am quite new in Django and Piston/tastypie, but have some experience using jsonrpc/xmlrpc libs in my Python apps.

Until now I have developed some modules, with a ServiceClass attached to the register of jsonrpc server who handle the request and call the methods in the ServiceClass.

When the class is attached to the register, a new instance of the ServiceClass is created, loading all the initial data and keeping it in memory, so every method called through jsonrpc can have access to the internal values in that instance.

Now, I am trying to do the same in Django with Piston or Tastypie. I followed this link http://www.robertshady.com/content/creating-very-basic-api-using-python-django-and-piston and other resources, and all the documentation I read is clear, showing the correct way to work with it:

  • Modify url.py to map requests like "/api/" to a specific handler.
  • Add a handler.py in the api application, extending the BaseHandler of Piston/Tastypie.

So I am wondering if its the correct way of working with Django and APIs, to create the instance of my ServiceClass (init the data, provide the methods) inside handler.py when I create the instance of the Handler extending the BaseHandler. Is this Handler class instantiated once when the server starts? What if my ServiceClass relies on some Model to load the data from it?

I want to avoid the framework to instantiate my class everytime a new request arrive to the /api/ application.

I will be glad to hear about any recommendation, Thanks,

Luchux
  • 803
  • 1
  • 7
  • 17

1 Answers1

1

Specifically for piston... You shouldnt really use the handler in terms of an instance. Its more like a metaclass that you set up with class attributes. These attributes control whicch model the handler will be bound to if any. And what fields it should show or what methods it supports.

Generally the request enter one of your methods and you then handle the request however you want, as an isolated state. If it needs to use a shared resource or use the model for queries, that part is up to you, being shared from some imported resource . You said you need a model which is why you would bind it to the handler as a class attribute and then query on it. You shouldnt really store state on the handler.

jdi
  • 90,542
  • 19
  • 167
  • 203
  • I see. Anyway, I need to keep the state. Why? well, my app is a SpellChecker, and I want to implement an API through which a user can query with a sentence and get the corrected one. Internally, my SpellChecker has a state (its trained with a corpus, has a dictionary of words, and an internal probabilistic model based on words distribution). I cant load this model every time a request arrives, just once at init. So, there is no model at all to link with. May be the solution is to implement the API outside the Django Framework at all, but I wanted to use native Throttling, Authentication,etc. – Luchux Mar 07 '12 at 17:31
  • 1
    Easy. Either make your SpellChecker class a Singleton (http://en.wikipedia.org/wiki/Singleton_pattern) or create an instance of the spell checker at the global level of your handler module and reference it in the handler methods. Here is a link showing how to do a singleton using a metaclass: http://stackoverflow.com/questions/31875/is-there-a-simple-elegant-way-to-define-singletons-in-python/33201#33201 – jdi Mar 07 '12 at 18:07
  • Also, piston and tastypies job is simply to get the request mapped correctly and routed into your methods. What you do inside of that to actually build your response is up to you. So i would say this is still the appropriate path for you. – jdi Mar 08 '12 at 06:13