Jakie są różnice między django-tastypie i djangorestframework? [Zamknięte]

Dlaczego miałbyś używać jednego nad drugim, aby udostępnić API dla swojej aplikacji Django?

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

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

Jako autor django-rest-framework mam oczywiste uprzedzenia;), ale moja, miejmy nadzieję, dość obiektywna opinia na ten temat jest taka:

TastyPie

• Jak zauważył Torsten, nie pomylisz się zbytnio z czymś napisanym przez tych samych ludzi, co niesamowity django-haystack . Z tego, co widziałem na ich liście mailingowej, Daniel Lindsey i inni są super pomocni, a Tastypie jest stabilny, wszechstronny i dobrze udokumentowany
• Wyróżnia się dostarczaniem rozsądnego zestawu domyślnych zachowań i niezwykle łatwym budowaniem interfejsu API w tym stylu.

Framework Django REST

• Udostępnia samoopisujące interfejsy API z możliwością przeglądania HTML. (Np. Zobacz samouczek API ). Możliwość nawigacji i interakcji z API bezpośrednio w przeglądarce to duża zaleta użyteczności.
• Próbuje pozostać blisko idiomów Django przez cały czas - zbudowany na podstawie widoków opartych na klasach Django itp. (Podczas gdy TastyPie pojawił się przed istnieniem CBV Django, więc używa własnej implementacji widoków opartych na klasach)
• Chciałbym pomyśleć, że podstawowa architektura jest całkiem ładnie zbudowana, odsprzęgnięta itp.

W każdym razie oba są dobre. Prawdopodobnie scharakteryzowałbym Tastypie jako dający rozsądny zestaw domyślnych ustawień po wyjęciu z pudełka, a framework REST jako bardzo ładnie oddzielony i elastyczny. Jeśli planujesz zainwestować dużo czasu w API, zdecydowanie polecam przejrzenie dokumentacji i bazy kodów każdego z nich i próbę znalezienia czegoś, co bardziej Ci odpowiada.

Oczywiście jest też „Why TastyPie?” w jego pliku README i „REST Framework 3” .

Zobacz także wpis na blogu Daniela Greenfelda na temat Wybieranie frameworka API dla Django z maja 2012 (Warto zauważyć, że było to jeszcze kilka miesięcy przed wydaniem dużego frameworka REST 2.0).

Również kilka wątków na Reddicie z ludźmi zadającymi to samo pytanie, od grudnia 2013 do lipca 2013 .

Oba są dobrym wyborem.

W przypadku filtrów smaczny kawałek jest mocniejszy po wyjęciu z pudełka. Jeśli masz widok, który odsłania model, możesz zrobić filtry nierówności w stylu Django:

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

lub zapytania OR:

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

są to możliwe dzięki djangorestframework, ale musisz napisać niestandardowe filtry dla każdego modelu.

Jeśli chodzi o śledzenie, byłem pod większym wrażeniem frameworka django-rest-framework. Tastypie próbuje wysłać e-mail settings.ADMINSo wyjątkach, kiedy DEBUG = False. Kiedy DEBUG = True, domyślny komunikat o błędzie jest w odcinkach JSON , który jest trudniejszy do odczytania.

EDYTUJ Nieaktualna odpowiedź, smaczny nie jest już tak naprawdę utrzymywany. Użyj frameworka Django REST, jeśli musisz wybrać framework do wykonania REST.

Aby zapoznać się z rzeczywistymi różnicami między nimi, przeczytaj ich dokumentację. Obie są mniej lub bardziej kompletne i dość dojrzałe.

Osobiście mam jednak tendencję do smakowitości. Wydaje się, że łatwiej jest to skonfigurować. Jest robiony przez tych samych ludzi, którzy stworzyli django-haystack, który jest niesamowity i według django-packages jest używany częściej niż framework Django REST.

Warto zauważyć, że odkąd zadano to pierwsze pytanie, DRF rośnie w siłę.

Jest bardziej aktywny z dwóch na githubie (zarówno pod względem zatwierdzeń, gwiazdek, rozwidleń, jak i współtwórców)

DRF obsługuje OAuth 2 i interfejs API z możliwością przeglądania.

Szczerze mówiąc, ta ostatnia funkcja to zabójca. Możliwość wskazania wszystkim moim programistom front-endowym API z możliwością przeglądania, gdy nie są pewni, jak coś działa, i powiedzą „Idź grać; dowiedzieć się ”jest fantastyczne.

Nie tylko dlatego, że oznacza to, że rozumieją to na własnych warunkach i wiedzą, że API naprawdę, zdecydowanie, absolutnie robi to, co mówi „dokumentacja”. W świecie integracji z API już sam ten fakt sprawia, że ​​DRF jest platformą do pokonania.

Cóż, Tastypie i DRF to doskonały wybór. Po prostu nie możesz się pomylić z żadnym z nich. (Nigdy nie pracowałem nad Pistonem; i to już od kilku dni nie jest popularne, więc nie mogę / nie mogę go komentować. Moim skromnym zdaniem: wyboru należy dokonać w oparciu o umiejętności, wiedzę i możliwości twojego zespołu (i twojego zespołu technicznego). Zamiast tego, co oferuje TastyPie i DRF, chyba że budujesz coś naprawdę dużego, takiego jak Quora, Facebook lub Google.

Osobiście zacząłem najpierw pracować nad TastyPie w czasie, gdy nawet nie znałem poprawnie django. To wszystko miało sens w tamtym czasie, ponieważ bardzo dobrze znałem tylko REST i HTTP, ale prawie nie posiadałem żadnej lub niewielkiej wiedzy na temat django. Ponieważ moim jedynym zamiarem było szybkie zbudowanie RESTful API, które miałyby zostać wykorzystane na urządzeniach mobilnych. Więc jeśli jesteś po prostu w stylu „Tak się składa, że ​​jestem wtedy nazywany django-new-bie”, nie myśl więcej, idź na TastyPie.

Ale jeśli mają wiele lat doświadczenia w pracy z Django, zna go na wylot i bardzo wygodne przy użyciu zaawansowanych pojęć (jak Wyświetleń Class Based, formy, model Validator, queryset, kierownik i model przypadkach oraz w jaki sposób wszystkie one oddziałują na siebie), * * idź na DRF. ** DFR jest oparty na widokach opartych na klasach django. DRF to idiomatyczne django. To tak, jakbyś pisał modele formularzy, walidatory itp. (Cóż, idiomatyczne django nie jest bliskie idiomatycznemu pythonowi. Jeśli jesteś ekspertem w Pythonie, ale nie masz doświadczenia z Django, możesz początkowo mieć trudności z dopasowaniem się do idiomatycznej filozofii django i które mają również znaczenie dla DRF). DRF zawiera wiele wbudowanych metod magicznych, takich jak django. Jeśli kochasz magiczne metody i filozofię django, to ** DRF ** jest właśnie dla Ciebie.

Teraz wystarczy odpowiedzieć na dokładne pytanie:

Tastypie:

Zalety:

1. Łatwy do rozpoczęcia i zapewniający podstawowe funkcje OOB (po wyjęciu z pudełka)
2. W większości przypadków nie będziesz mieć do czynienia z zaawansowanymi koncepcjami Django, takimi jak CBV, Formularze itp
3. Bardziej czytelny kod i mniej magii!
4. Jeśli twoje modele nie są ORM, zrób to.

Niedogodności:

1. Nie ściśle przestrzega idiomatycznego Django (pamiętaj, że filozofie Pythona i django są zupełnie inne)
2. Prawdopodobnie trochę trudno jest dostosować interfejsy API, gdy osiągniesz sukces
3. Brak O-Auth

DRF:

1. Śledź idiomatyczne django. (Jeśli znasz django od podszewki i czujesz się dobrze z CBV, Forms itp., Bez wątpienia wybierz to)
2. Zapewnia gotową funkcjonalność REST przy użyciu ModelViewSets. Jednocześnie zapewnia większą kontrolę nad dostosowywaniem za pomocą CustomSerializer, APIView, GenericViews itp.
3. Lepsze uwierzytelnianie. Łatwiejsze pisanie niestandardowych klas uprawnień. Działa bardzo dobrze i co ważne, bardzo łatwo, aby działał z bibliotekami innych firm i OAuth. DJANGO-REST-AUTH warto wspomnieć o LIBRARY do uwierzytelniania / uwierzytelniania społecznościowego / rejestracji. ( https://github.com/Tivix/django-rest-auth )

Niedogodności:

1. Jeśli nie znasz dobrze Django, nie idź na to.
2. Magia! Czasami bardzo trudno zrozumieć magię. Ponieważ został napisany na podstawie CBV django, które z kolei ma dość złożoną naturę. ( https://code.djangoproject.com/ticket/6735 )
3. Ma stromą krzywą uczenia się.

Czego osobiście użyłbym w moim następnym projekcie?

• Teraz nie jestem już fanem funkcji MAGIC i Out-of-box. Ponieważ wszystko to kosztuje * wielki koszt. * Zakładając, że mam wszystkie możliwości wyboru i kontrolę nad czasem i budżetem projektu, zacząłbym od czegoś lekkiego, takiego jak RESTLess ( https://github.com/toastdriven/restless ) (stworzonego przez twórcę TastyPie i django-haystack ( http: //haystacksearch.org/ )). I z tego samego powodu prawdopodobnie / zdecydowanie wybierz lekki framework sieciowy, taki jak Flask.

• Ale dlaczego? - Bardziej czytelny, prosty i łatwiejszy w zarządzaniu idiomatyczny kod Pythona (znany również jako Pythonic). Chociaż więcej kodu, ale ostatecznie zapewnia dużą elastyczność i dostosowanie.

  • Jawne jest lepsze niż niejawne.
  • Proste jest lepsze niż złożone.
  • Złożone jest lepsze niż skomplikowane.
  • Płaskie jest lepsze niż zagnieżdżone.
  • Rzadkie jest lepsze niż gęste.
  • Liczy się czytelność.
  • Specjalne przypadki nie są na tyle wyjątkowe, aby łamać zasady.

A co jeśli nie masz tylko wyboru oprócz Django i jednego z TastyPie i DRF?

• Teraz, znając dość dobrze Django, pójdę z ** DRF. **
• Czemu? - idiomatyczny djagno! (Nie podoba mi się to). Lepsza integracja OAuth i innych firm (moim ulubionym jest django-rest-auth).

Dlaczego więc wybrałeś DRF / TastyPie na pierwszym miejscu?

• Przede wszystkim pracowałem ze startupami i małymi firmami, które mają ograniczony budżet i czas; i musimy dostarczyć coś szybkiego i użytecznego. Django bardzo dobrze służy temu celowi. (Wcale nie mówię, że django nie jest skalowalne. Istnieją na nim strony takie jak Quora, Disquss, Youtube itp. Ale wszystko to wymaga czasu i więcej niż przeciętne umiejętności)

Mam nadzieję, że pomoże ci to podjąć lepszą decyzję.

Inne referencje - 1. Stan Tastypie ( http://toastdriven.com/blog/2014/may/23/state-tastypie/ ) 2. Jakie są różnice między django-tastypie a djangorestframework? ( Jakie są różnice między django-tastypie i djangorestframework? )

Korzystając z obu, jedną rzeczą, którą lubiłem (preferowałem) w Django Rest Framwork, jest to, że jest to bardzo spójne z Django.

Pisanie serializatorów modelu jest bardzo podobne do pisania formularzy modelu. Wbudowane widoki ogólne są bardzo podobne do ogólnych widoków Django dla HTML.

Django-tastypie nie jest już utrzymywane przez jego oryginalnego twórcę i stworzył własną, nową, lekką strukturę.

Obecnie powinieneś używać django-rest-framework z django, jeśli chcesz udostępnić swoje API.

Używają go duże korporacje. django-rest-framework jest głównym członkiem zespołu django i otrzymuje fundusze na utrzymanie django-rest-framework.

django-rest-framework ma również ogromną liczbę ciągle rosnących pakietów 3rd arty, które pomogą ci zbudować twoje API łatwiej i mniej kłopotów.

Część drf zostanie również włączona do właściwego django.

drf zapewnia więcej lepszych wzorów i narzędzi niż django-tastypie.

Krótko mówiąc, jest dobrze zaprojektowany, dobrze utrzymany, finansowany, zapewnia ogromne aplikacje innych firm, zaufane przez duże organizacje, łatwiejsze i mniej szablonowe itp.