[Chicago] Structuring a large Django API
brant.sean at gmail.com
Thu May 1 18:51:48 CEST 2014
I use absolute imports and my project is my base package. So inside
`project.api.resources.things` I would `from project.things.models import
On Thu, May 1, 2014 at 11:39 AM, Adam "Cezar" Jenkins <
emperorcezar at gmail.com> wrote:
> Thanks, What do you do when you have conflicting app and module names? For
> example, in your things.py above you also have a things app and in
> things.py you try 'from things.models import Thing'. That's been my issue
> when I tried that approach.
> On Thu, May 1, 2014 at 11:32 AM, Sean Brant <brant.sean at gmail.com> wrote:
>> I've used the following on a few projects with success:
>> One resource module that contains serializers and views per top-level api
>> resource. Most resource modules end up being under 50-100 lines of code. I
>> prefer this approach over api modules in my apps as I find my rest
>> resources don't always fit cleanly one-to-one with my app structure.
>> - Sean
>> On Thu, May 1, 2014 at 11:18 AM, Adam "Cezar" Jenkins <
>> emperorcezar at gmail.com> wrote:
>>> This is also on Stackoverflow:
>>> Right now I have a large project with an equally large API (done using
>>> django rest framework). The current structure is something like this:
>>> As you can guess, the views.py file is pretty big and I want to refactor
>>> this out. Currently I have a few options in front of me, the one I'm
>>> leaning towards is to put an 'api/v1' package into each app and use the api
>>> app to tie all the urls together and hold views that don't fall into an app.
>>> Does anyone have any experience with this and could provide guidance?
>>> Chicago mailing list
>>> Chicago at python.org
>> Chicago mailing list
>> Chicago at python.org
> Chicago mailing list
> Chicago at python.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Chicago