[Chicago] Structuring a large Django API

Sean Brant brant.sean at gmail.com
Thu May 1 18:32:37 CEST 2014


I've used the following on a few projects with success:

api
|-----urls.py
|-----models.py
|
----resources
    |-----users.py
    |-----things.py
    |-----...

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:
> http://stackoverflow.com/questions/23411571/structuring-a-large-api-in-a-django-project
>
> Right now I have a large project with an equally large API (done using
> django rest framework). The current structure is something like this:
>
> api
> |-----urls.py
> |-----models.py
> |
> ----v1
>     |-----views.py
>     |-----serializers.py
>     |-----permissions.py
>     |-----tests.py
>
> etc
>
> 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
> https://mail.python.org/mailman/listinfo/chicago
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/chicago/attachments/20140501/7bb4a6ee/attachment.html>


More information about the Chicago mailing list