CODEWITHSUNDEEP
djangoapidjango-pistontastypie
Luchux
Luchux

Reputation: 795

Correct way of initializing internal data for API in Django with Piston/Django-tastypie vs jsonrpc

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:

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,

Upvotes: 0

Views: 340

Answers (1)

jdi
jdi

Reputation: 92567

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.

Upvotes: 1

Related Questions