2014-04-02 42 views
6

Usiamo Django per creare back-end per applicazioni Web, fornendo API RESTful per l'app Ember.Django REST Framework - più modelli/API?

So (evolutivamente) abbiamo iniziato con la seguente struttura semplice:

project root 
| 
|-app1/models.py .... no views.py 
| 
|-app2/models.py .... no views.py 
| 
|-app3/models.py .... no views.py 
| 
\- restapi - provides REST API for app*: huge views.py, huge serializers.py, huge test.py 

Questo è facile da usare, soprattutto con vista sfogliabile del DRF:

@api_view(['GET']) 
def api_root(request, format=None): 
    return Response(
     { 
      'users': reverse('current-user-detail', request=request), 
      'interfacesettings': reverse('interface-settings', request=request), 
      ............................................................  
      'preferences': reverse('preferences', request=request), 
     } 
    ) 

modelli abbastanza poco abbiamo avuto/API per rendere il nostro restapi.app troppo complesso e disordinato e abbiamo iniziato a considerare l'utilizzo di qualcosa di più logico:

project root 
| 
|-app1/models.py .... views.py, serializers.py, tests.py 
| 
|-app2/models.py .... views.py, serializers.py, tests.py 
| 
|-app3/models.py .... views.py, serializers.py, tests.py 
| 
\- we do not need rest api anymore (but where will we put our api_root?) 

Dall'altro lato, abbiamo ora tutti i test complicati (che coinvolgono pochi modelli) in un posto che è conveniente. E riutilizziamo molto le funzioni dei serializzatori. E abbiamo una api_root. Quindi probabilmente potremmo avere qualcosa del genere:

project root 
| 
|-app1/models.py .... views.py (app1 API), serializers.py, tests.py 
| 
|-app2/models.py .... views.py (app2 API), serializers.py, tests.py 
| 
|-app3/models.py .... views.py (app3 API), serializers.py, tests.py 
| 
\- restapi - views.py (api_root), tests.py for complicated tests and serializers.py for common functions 

Quale approccio è migliore? E quali sono le migliori pratiche comuni qui? C'è qualche progetto aperto che possiamo dare un'occhiata?

risposta

9

Sto costruendo un'API riposante anche con Django come te. Quello che sto facendo è avere applicazioni indipendenti come il tuo ultimo esempio.

Abbiamo un'applicazione django "core", in cui abbiamo la radice api nelle viste e un file denominato "apis_urls.py" dove organizziamo tutti gli URL delle diverse app.

Abbiamo anche in questa app "core" un file "apis_filters.py" dove abbiamo i filtri che qualsiasi app con API può usare e "apis_permissions.py" per gestire le autorizzazioni per usare l'apis e importare sul altre app.

Così, alla fine stiamo lavorando in questo modo:

project root 
| 
|-app1/models.py .... views.py (app1 API), serializers.py, tests.py 
| 
|-app2/models.py .... views.py (app2 API), serializers.py, tests.py 
| 
|-app3/models.py .... views.py (app3 API), serializers.py, tests.py 
| 
\- core/views.py (api_root), apis_urls.py, apis_filters.py, apis_permissions.py 

Facciamo tutti i test nella loro corrispondente app.

E avendo l'apis_urls.py ci permette di avere tutti gli URL API come:

http://localhost/api/v1/example1 
http://localhost/api/v1/example2 

Nel urls.py principale abbiamo:

url(r'^api/v1/', include('core.apis_urls', namespace='api')), 

E sul app di base, sulla il “apis_urls.py”:

urlpatterns = patterns(
'', 
    ####### Users Urls 
    url(r'^users/$', users_views.UserListAPIView.as_view(), name='users-list-api'), 
    url(r'^me/$', users_views.LoggedUserRetrieveUpdateAPIView.as_view(), name='logged-user-detail-api'), 
    url(r'^users/(?P<username>[\[email protected]+-]+)/$', users_views.UserRetrieveAPIView.as_view(), name='users-detail-api'), 

    ####### Comments Urls 
    url(r'^comments/(?P<pk>[0-9]+)$', comments_api_views.CommentCreateAPIView.as_view(), name='comments-create-api'), 
) 

Spero che questo aiuto, è il modo in cui ho trovato più organizzare.

Problemi correlati