2014-04-02 11 views
6

हम वेब-ऐप बैकएंड बनाने के लिए Django का उपयोग करते हैं, एम्बर ऐप के लिए रीस्टफुल एपीआई प्रदान करते हैं।Django रीस्ट फ्रेमवर्क - एकाधिक मॉडल/एपीआई?

तो (evolutionally) हम निम्नलिखित सरल संरचना के साथ शुरू कर दिया:

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 

यह उपयोग करने के लिए, विशेष रूप से डीआरएफ के ब्राउज़ करने योग्य दृश्य के साथ आसान है:

@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), 
     } 
    ) 

काफी कुछ ही समय हम मिल गया है मॉडल/एपीआई को हमारे restapi.app तरीके को बहुत जटिल और गन्दा बनाने के लिए, और हमने कुछ और लॉजिकल का उपयोग करने पर विचार करना शुरू किया:

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?) 

दूसरी ओर, अब हमारे पास एक ही स्थान पर सभी जटिल परीक्षण (जिसमें कुछ मॉडल शामिल हैं) सुविधाजनक हैं। और हम serializers के कार्यों का बहुत उपयोग करते हैं। और हमारे पास एक api_root है। तो शायद हमारे पास ऐसा कुछ हो सकता है:

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 

कौन सा दृष्टिकोण बेहतर है? और यहां सामान्य सर्वोत्तम प्रथाएं क्या हैं? क्या कोई खुली परियोजना है जिसे हम देख सकते हैं?

उत्तर

9

मैं आपके जैसे Django के साथ एक आरामदायक एपीआई भी बना रहा हूं। मैं जो कर रहा हूं वह आपके पिछले उदाहरण की तरह एक एप्लिकेशन स्वतंत्र है।

हमारे पास "कोर" django एप्लिकेशन है, जहां हमारे पास विचारों में api_root है और "apis_urls.py" नाम की एक फ़ाइल है जहां हम विभिन्न ऐप्स से सभी यूआरएल व्यवस्थित करते हैं।

हमारे पास इस "कोर" ऐप में एक फ़ाइल "apis_filters.py" है, जहां हमारे पास फ़िल्टर हैं कि एपीआई के साथ कोई ऐप उपयोग कर सकता है और apis_permissions.py "को एपिस का उपयोग करने और आयात पर अनुमतियों का प्रबंधन करने के लिए" apis_permissions.py " दूसरे एप्लिकेशन।

तो अंत में हम इस तरह काम कर रहे हैं:

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 

हम उनकी संगत अनुप्रयोग में सभी परीक्षण कर सकते हैं।

और apis_urls.py होने हमारे जैसे सभी एपीआई यूआरएल की अनुमति देता है: मुख्य urls.py में

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

हमने:

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

और कोर एप्लिकेशन पर, पर "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'), 
) 

मुझे आशा है कि यह सहायता, जिस तरह से मैंने इसे और अधिक व्यवस्थित किया है।

संबंधित मुद्दे