¿Cuáles son las diferencias entre Django-Tastypie y DjangorestFramework? [cerrado

StackOverflow https://stackoverflow.com/questions/7303313

Pregunta

¿Por qué usarías uno sobre el otro, para exponer una API para tu aplicación Django?

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

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

¿Fue útil?

Solución

Como autor de Django-Rest-Framework, tengo un sesgo obvio;) pero mi opinión con suerte-fair-objective sobre esto es algo así como:

Tastipie

  • Como señaló Torsten, no vas a equivocarte con algo escrito por los mismos píos que los impresionantes django-haystack. Por lo que he visto en su lista de correo, Daniel Lindsey et al, son súper útiles, y Tastypie es estable, integral y bien documentada
  • Excelente en brindarle un conjunto sensato de comportamiento predeterminado y hacer que la construcción de una API con ese estilo sea increíblemente fácil.

Marco de descanso django

  • Te ofrece API de autodescripción de HTML para navegar. (Por ejemplo, ver el Tutorial API.) Ser capaz de navegar e interactuar con la API directamente en el navegador es una gran victoria de usabilidad.
  • Intenta mantenerse cerca de los modismos de Django en todo momento, construidos sobre las vistas de clase de Django, etc. (mientras que Tastypie apareció antes de que existieran los CBV de Django, por lo que utiliza su propia implementación de vistas basadas en clases)
  • 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 darle un conjunto sensato de valores predeterminados de la caja, y REST Framework como muy bien desacoplado y flexible. Si está planeando invertir mucho tiempo en la API, definiría que lo haga navegar a través de los documentos y la base de código de cada uno y tratar de tener una idea de la que se adapta más.

Obviamente, también está el '¿Por qué Tastypie?' sección en su lectura y el 'Rest Framework 3'.

Ver también la publicación de blog de Daniel Greenfeld en Elegir un marco API para Django, a partir de mayo de 2012 (vale la pena señalar que esto todavía pasaba unos meses antes del lanzamiento de Big Rest Framework 2.0).

También un par de hilos en Reddit con la gente que le hace esta misma pregunta, desde Diciembre de 2013 y julio 2013.

Otros consejos

Ambas son buenas opciones.

Para los filtros, Tastypie es más potente fuera de la caja. Si tiene una vista que expone un modelo, puede hacer filtros de desigualdad al estilo Django:

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

o o consultas:

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 trazados, me ha impresionado más el trabajo de frame-django. Tastypie intenta enviar un correo electrónico settings.ADMINS en excepciones cuando DEBUG = False. Cuando DEBUG = True, El mensaje de error predeterminado se está serializado JSON, que es más difícil de leer.

EDITAR Respuesta anticuada, Tastypie ya no se mantiene realmente. Use el marco de descanso de Django si tiene que elegir un marco para hacer reposo.

Para una visión general sobre 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 tastipie. Parece ser más fácil configurarlo. Se hace de las mismas personas que crearon django-haystack que es increíble y según paquetes de django Se usa más que el marco de descanso Django.

Vale la pena señalar que, dado que se le preguntó por primera vez, DRF se ha ido de fuerza en fuerza.

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

DRF tiene soporte OAuth 2 y la API navegable.

Honestamente para mí, esa última característica es el asesino. Poder señalar todos mis desarrolladores frontales en la API navegable cuando no están seguros de cómo funciona algo y decir 'Ve a jugar; Descubrir 'es fantástico.

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

Habiendo usado ambos, una cosa que me gustó (preferí) sobre el marco de descanso de Django es que es muy consistente con Django.

Escribir serializadores del modelo es muy similar a la escritura de formularios de modelos. Las vistas genéricas incorporadas son muy similares a las vistas genéricas de Django para HTML.

Bueno, Tastypie y DRF son excelentes opciones. Tu simplemente no poder Ve mal con cualquiera de ellos. (Nunca he trabajado en el pistón nunca; y ya no hay tendencias ahora, así que no lo haré / no puedo comentarlo. Da por sentado). En mi humilde opinión: Se debe elegir sobre las habilidades, el conocimiento y las capacidades de su equipo de su equipo tecnológico). En lugar de lo que ofrece Tastypie y DRF, a menos que esté fuera de curso que esté construyendo algo realmente grande como Quora, Facebook o Google.

Personalmente, terminé comenzando a trabajar primero en Tastypie en un momento en que ni siquiera conocía a Django correctamente. Todo tenía sentido en ese momento, solo conociendo el descanso y el http muy bien, pero con casi ningún o poco conocimiento sobre Django. Porque mi única intención era construir API reparadas en poco tiempo que se consumirían en dispositivos móviles. Entonces, si eres como ", me gusta en ese momento llamado django-new-bie", No pienses más para Tastypie.

Pero si tienes muchos años de experiencia trabajando con Django, lo sabe de adentro hacia afuera y muy cómodo usando conceptos avanzados (como vistas basadas en clases, formularios, validador de modelos, consultas, administrador y instancias de modelos y cómo todo lo que interactúan entre sí), ** Van por DRF. ** DFR es bases en las vistas de clase de Django. DRF es un django idiomático. Es como si estuvieras escribiendo formularios de modelos, validadores, etc. (bueno, el django idiomático no está cerca de la pitón idiomática. Si eres experto en Python pero no tienes experiencia con Django, entonces podría estar teniendo 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 filosofía mágicos Django ** Drf ** es solo para ti.

Ahora, solo para responder a la pregunta exacta:

Tastypie:

Ventajas:

  1. Fácil de comenzar y proporcionar funcionalidades básicas OOB (fuera de la caja)
  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 anormes, hágalo.

Desventajas:

  1. No sigue estrictamente el django idiomático (las filosofías de la mente de la mente y el django son bastante diferentes)
  2. Probablemente un poco difícil de personalizar API una vez que vayas a lo grande
  3. No O-Auth

DRF:

  1. Sigue el django idiomático. (Si conoce a Django de adentro hacia afuera, y muy cómodo con CBV, formularios, etc. sin ninguna duda, vaya por ello)
  2. Proporciona la funcionalidad de reposo de caja utilizando 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. Funcione muy bien y, importante, es muy fácil hacer que funcione con bibliotecas de terceros y OAuth. Vale la pena mencionar Django-Rest-Auth para la biblioteca para autenticación/socialautenticación/registro. (https://github.com/tivix/django-rest-auth)

Desventajas:

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

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

  • Ahora, no soy más fanático de la magia y las funcionalidades fuera de caja. Porque todo lo que tienen a un *gran costo. * Suponiendo que tengo todas las opciones y control sobre el tiempo y el presupuesto del proyecto, comenzaría con algo ligero como inquieto (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 marco web liviano como Matraz.

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

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

¿Qué pasa si no tienes otra opción que Django y uno de Tastypie y DRF?

  • Ahora, conociendo el Django razonablemente bien, iré con ** DRF. **
  • ¿Por qué? - Djagno idiomático! (Aunque no me encanta). La mejor integración de OAuth y terceros (Django-Rest-Auth es mi favorito).

Entonces, ¿por qué eligió el DRF/Tastypie en primer lugar?

  • Principalmente he trabajado con nuevas empresas y pequeñas empresas, que son apretadas en el presupuesto y el tiempo; y necesito entregar algo rápido y utilizable. Django sirve este propósito muy bien. (No estoy diciendo en absoluto que Django no es escalable. Hay sitios web como Quora, Disquss, YouTube, etc., lo ejecutan. Pero todo lo que requiere tiempo y habilidades más 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?)

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 utilizando. Django-Rest-Framework es un miembro central del equipo de Django y obtiene fondos para mantener el trabajo de frame-rest-frame.

Django-Rest-Framework también tiene una gran cantidad de paquetes de 3er Arty en constante crecimiento que lo ayudarán a construir sus API más fácilmente con menos problemas.

Algunas parte de DRF también se fusionarán en Django propiamente dicho.

DRF proporciona más patrones y herramientas mejores que Django-Tastypie.

En resumen, está bien diseñado, bien mantenido, financiado, proporcionan enormes aplicaciones de terceros, confiadas por organizaciones grandes, más fáciles y menos calderas, etc. sobre Tastypie.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top