Python Module in Django
Definitely go for "way #1".  Keeping an independent layer for your service(s) API will help a lot later when you have to enhance that layer for reliability or extending the API.
Stay away from singletons, they're just global variables with a new name.  Use an appropriate life cycle for your interface objects.  The obvious "instantiate for each request" is not the worst idea, and it's easier to optimize that if needed (by caching and/or memoization) than it's to unroll global vars everywhere.
Keep in mind that web applications are supposed to be several processes on a "shared nothing" design; the only shared resources must be external to the app: database, queue managers, cache storage.
Finally, try to avoid using this API directly from the view functions/CBV.  Either use them from your models, or write a layer conceptually similar to the way models are used from the views.  No need of an ORM-like api, but keep any 'business process' away from the views, which should be concerned only with the presentation and high level operations.  Think "thick model, thin views" with your APIs as a new kind of models.
I am building my first Django web application and I need a bit of advice on code layout. 
I need to integrate it with several other applications that are exposed through RESTful APIs and additionally Django's internal data. I need to develop the component that will pull data from various sources, django's DB, format it consistently for output and return it for rendering by the template. 
I am thinking of the best way to write this component. There are a couple of ways to proceed and I wanted to solicit some feedback from more experienced web developers on things I may have missed. 
Way #1
Develop a completely standalone objects for interacting with other applications via their APIs, etc... This would not have anything related with django and test independently. Then in django, import this module in the views that need it, run object methods to get required data, etc... 
If I need to access any of this functionality via a GET request (like through JavaScript), I can have a dedicated view that imports the module and returns json. 
Way #2
Develop this completely as django view(s) expose as a series of GET/POST calls that would all call each other to get the work done. This would be directly tied in the application. 
Way #3
Start with Way #1, but instead of creating a view, package it as a django app. Develop unit tests on the app as well as the individual objects. 
I think that way 1 or 3 would be very much encapsulated and controlled.
Way 2 would be more complicated, but facilitate higher component re-use. 
What is better from a performance standpoint? If I roll with Way #1 or 3, would an instance of the object be instantiated for each request? 
If so this approach may be a bit too heavy for this. If I proceed with this, can they be singletons? 
Anyway, I hope this makes sense. 
thanks in advance.