Sự khác biệt giữa django-ngonpie và djangorestframework là gì? [đóng cửa]

Tại sao bạn lại sử dụng cái này để làm API cho ứng dụng Django?

http://pypi.python.org/pypi/djangorestframework/

http://pypi.python.org/pypi/django-tastypie

Là tác giả của django-rest-framework, tôi đã có một thành kiến ​​rõ ràng;) nhưng ý kiến ​​hy vọng khá khách quan của tôi về điều này là một cái gì đó như:

TastyPie

• Như Torsten đã lưu ý, bạn sẽ không đi quá xa với một cái gì đó được viết bởi cùng một peeps như django-haystack tuyệt vời . Từ những gì tôi thấy trong danh sách gửi thư của họ, Daniel Lindsey và cộng sự là rất hữu ích, và Tastypie ổn định, toàn diện và được ghi chép tốt
• Tuyệt vời trong việc cung cấp cho bạn một tập hợp hành vi mặc định hợp lý và làm cho việc xây dựng API với phong cách đó cực kỳ dễ dàng.

Khung Django REST

• Cung cấp cho bạn các API tự mô tả có thể duyệt HTML. (EG, xem API hướng dẫn .) Có thể điều hướng và tương tác trực tiếp với API trong trình duyệt là một chiến thắng khả năng sử dụng lớn.
• Cố gắng theo sát các thành ngữ Django trong suốt - được xây dựng dựa trên các quan điểm dựa trên lớp của Django, v.v ... (Trong khi TastyPie xuất hiện trước khi CBV của Django tồn tại, do đó sử dụng triển khai chế độ xem dựa trên lớp)
• Tôi muốn nghĩ rằng kiến ​​trúc cơ bản được xây dựng khá độc đáo, tách rời, v.v ...

Trong mọi trường hợp, cả hai đều tốt. Tôi có thể mô tả Tastypie là cung cấp cho bạn một bộ mặc định hợp lý ra khỏi hộp và khung REST là rất tách rời và linh hoạt. Nếu bạn dự định đầu tư nhiều thời gian vào API, tôi sẽ khuyên bạn nên duyệt qua các tài liệu & cơ sở mã của từng loại và cố gắng cảm nhận xem nó phù hợp với bạn hơn.

Rõ ràng, cũng có 'Tại sao TastyPie?' phần trong đó là README và 'REST framework 3' .

Xem thêm bài đăng trên blog của Daniel Greenfeld về Chọn khung API cho Django , từ tháng 5 năm 2012 (Đáng lưu ý rằng đây vẫn là một vài tháng trước khi phát hành REST framework 2.0 lớn).

Ngoài ra một vài chủ đề trên Reddit với những người hỏi cùng câu hỏi này, từ tháng 12 năm 2013 và tháng 7 năm 2013 .

Cả hai đều là lựa chọn tốt.

Đối với các bộ lọc, ngon miệng là mạnh mẽ hơn ra khỏi hộp. Nếu bạn có chế độ xem hiển thị mô hình, bạn có thể thực hiện các bộ lọc bất bình đẳng theo phong cách Django:

http://www.example.com/api/person?age__gt=30

hoặc truy vấn OR:

http://www.example.com/api/mymodel?language__in=en&language__in=fr

những điều này là có thể với djangorestframework, nhưng bạn phải viết các bộ lọc tùy chỉnh cho từng mô hình.

Đối với tracebacks, tôi đã ấn tượng hơn với django-rest-framework. Tastypie cố gắng gửi email settings.ADMINSvề các ngoại lệ khi DEBUG = False. Khi DEBUG = True, thông báo lỗi mặc định là JSON được tuần tự hóa , khó đọc hơn.

EDIT Câu trả lời lỗi thời, ngon miệng không thực sự được duy trì nữa. Sử dụng khung Django REST nếu bạn phải chọn khung để làm REST.

Để biết tổng quan về sự khác biệt thực tế giữa cả hai bạn nên đọc tài liệu của họ. Cả hai đều ít nhiều hoàn thiện và khá trưởng thành.

Cá nhân tôi có xu hướng ngon miệng mặc dù. Nó có vẻ dễ dàng hơn để thiết lập nó. Nó được thực hiện từ cùng những người đã tạo ra django-haystack , điều này thật tuyệt vời và theo gói django, nó được sử dụng nhiều hơn so với khung Django REST.

Điều đáng chú ý là vì đây là lần đầu tiên DRF yêu cầu đã tăng cường sức mạnh.

Đó là hoạt động tích cực hơn của cả hai trên github (cả về cam kết, sao, dĩa và cộng tác viên)

DRF có hỗ trợ OAuth 2 và API có thể duyệt.

Thành thật với tôi rằng tính năng cuối cùng là kẻ giết người. Có thể trỏ tất cả các nhà phát triển mặt trước của tôi vào API có thể duyệt được khi họ không chắc chắn cách thức hoạt động của một cái gì đó và nói 'Đi chơi; tìm ra 'là tuyệt vời.

Không phải ít nhất bởi vì điều đó có nghĩa là họ hiểu điều đó theo cách riêng của họ và biết rằng API thực sự, chắc chắn, hoàn toàn làm những gì 'tài liệu' nói. Trong thế giới tích hợp với API, chỉ riêng thực tế đó đã khiến DRF trở thành khuôn khổ để đánh bại.

Chà, Tastypie và DRF đều là những lựa chọn tuyệt vời. Bạn chỉ đơn giản là không thể đi sai với một trong số họ. (Tôi chưa từng làm việc với Piston bao giờ; và loại này không còn là xu hướng nữa bây giờ một ngày nên sẽ không / không thể nhận xét về nó. Được thực hiện cho cấp.). Theo ý kiến ​​khiêm tốn của tôi: Nên lựa chọn các kỹ năng, kiến ​​thức và khả năng của bạn (và nhóm công nghệ của bạn). Thay vì dựa trên những gì TastyPie và DRF cung cấp, trừ khi bạn không xây dựng một thứ gì đó thực sự lớn như Quora, Facebook hay Google.

Cá nhân tôi, cuối cùng tôi đã bắt đầu làm việc trên TastyPie vào thời điểm tôi thậm chí còn không biết django đúng cách. Tất cả đều có ý nghĩa vào thời điểm đó, chỉ biết REST và HTTP rất tốt nhưng hầu như không có hoặc có ít kiến ​​thức về django. Bởi vì ý định duy nhất của tôi là xây dựng các API RESTful trong thời gian không được sử dụng trong các thiết bị di động. Vì vậy, nếu bạn giống như 'Tôi tình cờ ở thời điểm đó được gọi là django-new-bie', đừng nghĩ nhiều hơn cho TastyPie.

Nhưng nếu bạn có nhiều năm kinh nghiệm làm việc với Django, biết điều đó từ bên ngoài và rất thoải mái khi sử dụng các khái niệm nâng cao (như Chế độ xem dựa trên lớp, Biểu mẫu, Trình xác thực mô hình, Truy vấn, Trình quản lý và Mô hình và cách tất cả chúng tương tác với nhau), * * đi DRF. ** DFR dựa trên quan điểm dựa trên lớp của django. DRF là django thành ngữ. Giống như bạn đang viết các mẫu mô hình, trình xác nhận, v.v. (Chà, django thành ngữ không ở đâu gần với con trăn thành ngữ. Nếu bạn là chuyên gia về trăn nhưng không có kinh nghiệm với Django thì ban đầu bạn có thể gặp khó khăn với triết lý django thành ngữ đó cũng là vấn đề DRF). DRF đi kèm với rất nhiều phương pháp ma thuật sẵn có giống như django. Nếu bạn yêu thích các phương pháp và triết lý ma thuật django ** DRF ** chỉ dành cho bạn.

Bây giờ, chỉ để trả lời chính xác câu hỏi:

Tastypie:

Ưu điểm:

1. Dễ dàng bắt đầu và cung cấp các chức năng cơ bản OOB (ngoài hộp)
2. Hầu hết thời gian bạn sẽ không phải đối phó với các khái niệm Django nâng cao như CBV, Biểu mẫu, v.v.
3. Mã dễ đọc hơn và ít phép thuật hơn!
4. Nếu mô hình của bạn là KHÔNG-ORM, hãy chọn nó.

Nhược điểm:

1. Không tuân thủ nghiêm ngặt thành ngữ Django (triết lý của python và django khá khác nhau)
2. Có lẽ hơi khó khăn để tùy chỉnh API một khi bạn lớn
3. Không có xác thực

DRF:

1. Thực hiện theo django thành ngữ. (Nếu bạn biết django từ trong ra ngoài, và rất thoải mái với CBV, Forms vv mà không có nghi ngờ gì về nó)
2. Cung cấp chức năng REST ngoài hộp bằng ModelViewSets. Đồng thời, cung cấp khả năng kiểm soát tùy chỉnh tốt hơn bằng cách sử dụng CustomSerializer, APIView, GenericViews, v.v.
3. Xác thực tốt hơn. Dễ dàng hơn để viết các lớp cho phép tùy chỉnh. Hoạt động rất tốt và quan trọng là rất dễ dàng để làm cho nó hoạt động với các thư viện bên thứ 3 và OAuth. DJANGO-REST-AUTH đáng được đề cập đến THƯ VIỆN cho Auth / SocialAuthentication / Đăng ký. ( https://github.com/Tivix/django-rest-auth )

Nhược điểm:

1. Nếu bạn không biết rõ về Django, đừng tham gia.
2. Ma thuật! Một thời gian rất khó hiểu phép thuật. Bởi vì nó được viết trên CBV của django, vốn lần lượt khá phức tạp trong tự nhiên. ( https://code.djangoproject.com/ticket/6735 )
3. Có đường cong học tập dốc.

Cá nhân tôi sẽ sử dụng những gì trong dự án tiếp theo của tôi?

• Bây giờ, tôi không còn là một fan hâm mộ của các chức năng MAGIC và Out-of-box. Bởi vì tất cả họ đến với một chi phí * lớn. * Giả sử tôi có tất cả các lựa chọn và kiểm soát thời gian và ngân sách dự án, tôi sẽ bắt đầu với thứ gì đó nhẹ như RESTLess ( https://github.com/toastdriven/restless ) (được tạo bởi TastyPie và django-haystack ( http: //haystacksearch.org/ )). Và đối với cùng một vấn đề có lẽ / chắc chắn chọn khung web nhẹ như Flask.

• Nhưng tại sao? - Mã python (hay pythonic) dễ đọc hơn, đơn giản và dễ quản lý hơn. Mặc dù nhiều mã hơn nhưng cuối cùng cung cấp sự linh hoạt và tùy biến tuyệt vời.

  • Rõ ràng là tốt hơn so với ngầm.
  • Đơn giản là tốt hơn phức tạp.
  • Phức tạp tốt hơn phức tạp.
  • Bằng phẳng là tốt hơn so với lồng nhau.
  • Thưa thì tốt hơn dày đặc.
  • Tính dễ đọc.
  • Trường hợp đặc biệt không đủ đặc biệt để phá vỡ các quy tắc.

Điều gì sẽ xảy ra nếu bạn không có lựa chọn nào khác ngoài Django và một trong TastyPie và DRF?

• Bây giờ, khi biết Django hợp lý, tôi sẽ đi với ** DRF. **
• Tại sao? - djagno thành ngữ! (Tôi không thích nó mặc dù). Tích hợp OAuth và bên thứ 3 tốt hơn (django-rest-auth là sở thích của tôi).

Vậy thì tại sao bạn lại chọn DRF / TastyPie ngay từ đầu?

• Chủ yếu tôi đã làm việc với các công ty mới thành lập và các công ty nhỏ, vốn rất eo hẹp về ngân sách và thời gian; và cần phải cung cấp một cái gì đó nhanh chóng và có thể sử dụng. Django phục vụ mục đích này rất tốt. (Tôi hoàn toàn không nói rằng django không thể mở rộng được. Có những trang web như Quora, Disquss, Youtube, v.v. chạy trên đó.

Tôi hy vọng, nó sẽ giúp bạn đưa ra quyết định tốt hơn.

Các tài liệu tham khảo khác - 1. Trạng thái của Tastypie ( http://toastdriven.com/blog/2014/may/23/state-tastypie/ ) 2. Sự khác biệt giữa django-ngonpie và djangorestframework là gì? ( Sự khác biệt giữa django-ngonpie và djangorestframework là gì? )

Đã sử dụng cả hai, một điều mà tôi thích (ưa thích) về Django Rest Framwork là nó rất phù hợp với Django.

Viết tuần tự mô hình rất giống với viết mẫu mô hình. Chế độ xem Chung được xây dựng rất giống với Chế độ xem chung của Django cho HTML.

Django-ngonpie không còn được duy trì bởi người sáng tạo ban đầu và ông đã tạo ra một khung trọng lượng nhẹ mới của riêng mình.

Hiện tại bạn nên sử dụng django-rest-framework với django nếu bạn sẵn sàng để lộ API của mình.

Các tập đoàn lớn đang sử dụng nó. django-rest-framework là thành viên cốt lõi của nhóm django và anh ấy nhận được tài trợ để duy trì django-rest-framework.

django-rest-framework cũng có số lượng lớn các gói arty thứ 3 đang phát triển, điều này sẽ giúp bạn xây dựng API dễ dàng hơn với ít rắc rối hơn.

Một số phần của drf cũng sẽ được hợp nhất trong django thích hợp.

drf cung cấp nhiều mẫu và công cụ tốt hơn sau đó django-ngonpie.

Nói tóm lại, nó được thiết kế tốt, được bảo trì tốt, được tài trợ, cung cấp các ứng dụng bên thứ 3 khổng lồ, được các tổ chức lớn tin cậy, dễ dàng hơn và ít nồi hơi hơn v.v.