¿Cuáles son las diferencias entre django-tastypie y djangorestframework? [cerrado]

¿Por qué usaría uno sobre el otro para exponer una API para su aplicación Django?

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

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

Como autor de django-rest-framework, tengo un sesgo obvio;) pero mi opinión con suerte bastante objetiva sobre esto es algo así como:

TastyPie

• Como señaló Torsten, no vas a equivocarte mucho con algo escrito por los mismos personajes que el increíble django-haystack . Por lo que he visto en su lista de correo, Daniel Lindsey et al son muy útiles, y Tastypie es estable, completo y bien documentado.
• Se destaca por brindarle un conjunto sensato de comportamiento predeterminado y hacer que construir una API con ese estilo sea increíblemente fácil.

Marco Django REST

• Le ofrece API de autodescripción navegable en HTML. (Por ejemplo, vea la API tutorial .) Poder navegar e interactuar con la API directamente en el navegador es una gran victoria de usabilidad.
• Intenta mantenerse cerca de las expresiones idiomáticas de Django en todo momento, construido sobre las vistas basadas en clases de Django, etc.
• Me gustaría pensar que la arquitectura subyacente está bastante bien construida, desacoplada, etc.

En cualquier caso, ambos son buenos. Probablemente caracterizaría a Tastypie como un conjunto sensible de valores predeterminados, y el marco REST como muy bien desacoplado y flexible. Si planea invertir mucho tiempo en la API, definitivamente recomendaría navegar a través de los documentos y la base de código de cada uno e intentar tener una idea de lo que más le conviene.

Obviamente, también está el '¿Por qué TastyPie?' sección en su archivo README y el 'REST framework 3' .

Consulte también la publicación del blog de Daniel Greenfeld sobre Elección de un marco API para Django , de mayo de 2012 (vale la pena señalar que esto aún fue unos meses antes del gran lanzamiento del marco REST 2.0).

También un par de hilos en Reddit con personas que hacen esta misma pregunta, desde diciembre de 2013 y julio de 2013 .

Ambas son buenas elecciones.

Para los filtros, tastypie es más potente de fábrica. Si tiene una vista que expone un modelo, puede hacer filtros de desigualdad de estilo Django:

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

o consultas OR:

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

Estos son posibles con djangorestframework, pero debe escribir filtros personalizados para cada modelo.

Para los rastreos, me ha impresionado más django-rest-framework. Tastypie intenta enviar correos electrónicos settings.ADMINSsobre excepciones cuando DEBUG = False. Cuando DEBUG = True, el mensaje de error predeterminado es JSON serializado , que es más difícil de leer.

EDITAR Respuesta desactualizada, tastypie ya no se mantiene realmente. Utilice el marco REST de Django si tiene que elegir un marco para hacer REST.

Para obtener una descripción general de las diferencias reales entre ambos, debe leer su documentación. Ambos son más o menos completos y bastante maduros.

Sin embargo, yo personalmente tiendo a tastypie. Parece ser más fácil configurarlo. Está hecho de las mismas personas que crearon django-haystack, que es increíble y, según django-packages , se usa más que el marco Django REST.

Vale la pena señalar que desde que se le preguntó por primera vez, DRF ha ido fortaleciéndose.

Es el más activo de los dos en github (tanto en términos de commits, estrellas, tenedores y contribuyentes)

DRF tiene soporte para OAuth 2 y la API navegable.

Sinceramente para mí, esa última característica es el asesino. Poder señalar a todos mis desarrolladores de front-end a la API navegable cuando no están seguros de cómo funciona algo y dicen 'Go play; averiguar "es fantástico.

No menos importante porque significa que pueden entenderlo en sus propios términos y saber que la API realmente, definitivamente, hace absolutamente lo que dice la 'documentación'. En el mundo de la integración con las API, solo ese hecho hace que DRF sea el marco para vencer.

Bueno, Tastypie y DRF son excelentes opciones. Simplemente no puedes equivocarte con ninguno de ellos. (No he trabajado en Piston nunca; y ya no es tendencia, por lo que no quiero / no puedo comentarlo. Tomado por concedido). En mi humilde opinión: se debe elegir entre las habilidades, el conocimiento y las capacidades de usted (y de su equipo de tecnología). En lugar de lo que ofrece TastyPie y DRF, a menos que, por supuesto, esté creando algo realmente grande como Quora, Facebook o Google.

Personalmente, terminé trabajando primero en TastyPie en un momento en que ni siquiera conocía django correctamente. Todo tenía sentido en ese momento, solo conocía REST y HTTP muy bien, pero con poco o nada de conocimiento sobre django. Porque mi única intención era construir API RESTful en poco tiempo que se consumirían en dispositivos móviles. Entonces, si eres como 'En ese momento me llaman django-new-bie', no pienses más en TastyPie.

Pero si tiene muchos años de experiencia trabajando con Django, lo sabe de adentro hacia afuera y se siente muy cómodo usando conceptos avanzados (como Vistas basadas en clases, Formularios, Validador de modelos, QuerySet, Manager e Instancias de modelos y cómo interactúan entre sí), * * ir por DRF. ** DFR se basa en las vistas basadas en clases de django. DRF es idiomático django. Es como si estuvieras escribiendo formularios modelo, validadores, etc. (Bueno, django idiomático no está cerca de ser una pitón idiomática. Si eres un experto en python pero no tienes experiencia con Django, es posible que tengas dificultades para encajar inicialmente en la filosofía idiomática de django y para eso también importa DRF). DRF viene con muchos métodos mágicos incorporados como django. Si amas los métodos y la filosofía mágicos de django ** DRF ** es solo para ti.

Ahora, solo para responder la pregunta exacta:

Tastypie:

Ventajas:

1. Fácil de comenzar y proporcionar funcionalidades básicas OOB (listo para usar)
2. La mayoría de las veces no tratará con conceptos avanzados de Django como CBV, formularios, etc.
3. ¡Código más legible y menos magia!
4. Si sus modelos NO SON ORM, hágalo.

Desventajas

1. No sigue estrictamente a Django idiomático (las filosofías de Python y Django son muy diferentes)
2. Probablemente sea un poco difícil personalizar las API una vez que lo haces
3. No O-Auth

DRF:

1. Sigue a django idiomático. (Si conoce django de adentro hacia afuera, y muy cómodo con CBV, Forms, etc., sin duda, hágalo)
2. Proporciona funcionalidad REST lista para usar mediante ModelViewSets. Al mismo tiempo, proporciona un mayor control para la personalización utilizando CustomSerializer, APIView, GenericViews, etc.
3. Mejor autenticación Más fácil de escribir clases de permisos personalizados. Trabaja muy bien y, lo que es más importante, es muy fácil hacerlo funcionar con bibliotecas de terceros y OAuth. Vale la pena mencionar DJANGO-REST-AUTH LIBRARY para Auth / SocialAuthentication / Registration. ( https://github.com/Tivix/django-rest-auth )

Desventajas

1. Si no conoces muy bien a Django, no busques esto.
2. ¡Magia! Algún tiempo muy difícil de entender la magia. Porque ha sido escrito sobre el CBV de django, que a su vez es de naturaleza bastante compleja. ( https://code.djangoproject.com/ticket/6735 )
3. Tiene una curva de aprendizaje empinada.

Personalmente, ¿qué usaría en mi próximo proyecto?

• Ahora, ya no soy fanático de MAGIC y de las funcionalidades listas para usar. Porque todos vienen a un * gran costo. * Suponiendo que tenga todas las opciones y el control sobre el tiempo y el presupuesto del proyecto, comenzaría con algo ligero como RESTLess ( https://github.com/toastdriven/restless ) (creado por el creador de TastyPie y django-haystack ( http: //haystacksearch.org/ )). Y para el mismo asunto, probablemente / definitivamente elija el framework web ligero como Flask.

• ¿Pero por qué? - Código de Python idiomático (también conocido como pitónico) más legible, simple y manejable. Aunque más código pero eventualmente proporciona una gran flexibilidad y personalización.

  • Explícito es mejor que implícito.
  • Simple es mejor que complejo.
  • Complejo es mejor que complicado.
  • Plano es mejor que anidado.
  • Escaso es mejor que denso.
  • La legibilidad cuenta.
  • Los casos especiales no son lo suficientemente especiales como para romper las reglas.

¿Qué pasa si no tienes más remedio que Django y uno de TastyPie y DRF?

• Ahora, conociendo el Django razonablemente bien, iré con ** DRF. ** **
• ¿Por qué? - idiota djagno! (Aunque no me encanta). Mejor integración de OAuth y de terceros (django-rest-auth es mi favorito).

Entonces, ¿por qué elegiste DRF / TastyPie en primer lugar?

• Sobre todo he trabajado con startups y pequeñas empresas, que tienen poco presupuesto y tiempo; y necesita entregar algo rápido y utilizable. Django cumple muy bien este propósito. (No estoy diciendo en absoluto que django no sea escalable. Hay sitios web como Quora, Disquss, Youtube, etc. que se ejecutan en él. Pero todo requiere tiempo y más que habilidades promedio)

Espero que te ayude a tomar una mejor decisión.

Otras referencias: 1. El estado de Tastypie ( http://toastdriven.com/blog/2014/may/23/state-tastypie/ ) 2. ¿Cuáles son las diferencias entre django-tastypie y djangorestframework? ( ¿Cuáles son las diferencias entre django-tastypie y djangorestframework? )

Habiendo usado ambos, una cosa que me gustó (preferí) sobre Django Rest Framwork es que es muy consistente con Django.

Escribir serializadores de modelos es muy similar a escribir formularios de modelos. Las vistas genéricas integradas son muy similares a las vistas genéricas de Django para HTML.

Django-tastypie ya no es mantenido por su creador original y creó un nuevo marco de peso ligero propio.

En la actualidad, debe usar django-rest-framework con django si está dispuesto a exponer su API.

Las grandes corporaciones lo están usando. django-rest-framework es un miembro central del equipo de django y obtiene fondos para mantener django-rest-framework.

django-rest-framework también tiene una gran cantidad de paquetes de 3.a artillería en constante crecimiento que lo ayudarán a construir sus API más fácilmente con menos problemas.

Parte de drf también se fusionará en django propiamente dicho.

drf proporciona mejores patrones y herramientas que django-tastypie.

En resumen, está bien diseñado, bien mantenido, financiado, proporciona enormes aplicaciones de terceros, confiables por grandes organizaciones, más fácil y menos repetitivo, etc. sobre tastypie.