framework example ejemplo create django api rest django-rest-framework

example - ¿Cuáles son las diferencias entre django-tastypie y djangorestframework?



django rest framework serializer (7)

Ambas son buenas elecciones.

Para los filtros, tastypie es más poderoso listo para usar. 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 consultas OR:

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

esto es posible con djangorestframework, pero debe escribir filtros personalizados para cada modelo.

Para los rastreos, me he quedado más impresionado con django-rest-framework. Tastypie intenta enviar settings.ADMINS correo electrónico. ADMINISTRACIONES sobre excepciones cuando DEBUG = False . Cuando DEBUG = True , el mensaje de error predeterminado es JSON serializado , que es más difícil de leer.

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

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

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

Bueno, Tastypie y DRF son excelentes opciones. Simplemente no puedes equivocarte con ninguno de ellos. (No he trabajado en Piston alguna vez, y ahora ya no está en tendencia, así que no puedo / no puedo comentar sobre eso. Tomado por concedido). En mi humilde opinión: la elección debe hacerse en las habilidades, el conocimiento y las capacidades de usted (y su equipo técnico). En lugar de lo que ofrece TastyPie y DRF, a menos que esté fuera de curso, está creando algo realmente grande como Quora, Facebook o Google.

Personalmente, terminé trabajando primero en TastyPie en un momento en que ni siquiera sabía django correctamente. Todo tenía sentido en ese momento, solo conocía REST y HTTP muy bien, pero casi sin conocimiento de django. Porque mi única intención era crear API RESTful en un instante que se consumiría en dispositivos móviles. Entonces, si usted es como ''en ese momento me llamo django-new-bie'', no creo que vaya más por TastyPie.

Pero si tiene muchos años de experiencia trabajando con Django, lo sabe de cerca y se siente muy cómodo usando conceptos avanzados (como Vistas basadas en clase, Formularios, Validador de modelo, QuerySet, Instancias de modelo y administrador y cómo interactúan entre sí), * * ir por DRF. ** DFR se basa en las vistas basadas en clases de django. DRF es django idiomático. Es como si estuvieras escribiendo formularios modelo, validadores, etc. (Bueno, el django idiomático no está cerca de la pitón idiomática. Si eres un experto en python pero no tienes experiencia con Django, puede que tengas un tiempo difícil para adaptarte a la filosofía django idiomática y para eso también importa el DRF). DRF viene con muchos métodos mágicos incorporados al igual que django. Si te encantan los métodos mágicos y la filosofía de django ** DRF ** es justo para ti.

Ahora, solo para responder 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 mágico!
  4. Si tus modelos no son ORM, hazlo.

Desventajas:

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

DRF:

  1. Sigue el django idiomático. (Si conoce django al revés, y se siente muy cómodo con CBV, Formularios, etc., sin duda, vaya por él)
  2. Proporciona la funcionalidad REST fuera de la caja usando 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 escribir clases de permisos personalizados. Trabaja muy bien y lo más importante es que es muy fácil hacerlo funcionar con bibliotecas de terceros y OAuth. DJANGO-REST-AUTH vale la pena mencionar LIBRARY para Auth / SocialAuthentication / Registration. ( https://github.com/Tivix/django-rest-auth )

Desventajas:

  1. Si no conoces muy bien a Django, no te vayas por esto.
  2. ¡Magia! Algún tiempo muy difícil de entender la magia. Porque está 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 de las funcionalidades MAGIC y Out-of-Box. Porque todos tienen 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 RESTLess ( https://github.com/toastdriven/restless ) (creado por el creador de TastyPie y django-haystack ( django-haystack )). Y para el mismo asunto probablemente / definitivamente elija el marco web ligero como Flask.

  • ¿Pero por qué? - Código de pitón idiomático (aka pitónico) más legible, simple y manejable. Aunque hay más código, pero finalmente proporciona 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.
    • Sparse 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 a Django razonablemente bien, iré con ** DRF. **
  • ¿Por qué? - Idiomático djagno! (No me gusta, sin embargo). Mejor integración de OAuth y de terceros (django-rest-auth es mi favorito).

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

  • Sobre todo, he trabajado con nuevas empresas y pequeñas empresas, que tienen poco presupuesto y tiempo; y necesita entregar algo rápido y utilizable. Django sirve este propósito muy bien. (No estoy diciendo en absoluto que django no sea escalable. Hay sitios web como Quora, Disquss, Youtube, etc.), pero todo esto 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? ( votes )

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

TastyPie

  • Como señaló Torsten, no vas a equivocarte demasiado con algo escrito por los mismos píos que el impresionante django-haystack . Por lo que he visto en su lista de correo, Daniel Lindsey y otros son súper útiles, y Tastypie es estable, completo y está bien documentado.
  • Sobresale en brindarle un conjunto razonable de comportamientos predeterminados y hacer que la creación de una API con ese estilo sea increíblemente fácil.

Marco Django REST

  • Te brinda API autodescriptivas de navegación HTML. (Por ejemplo, consulte la API del tutorial .) Ser capaz de navegar e interactuar con la API directamente en el navegador es una gran ganancia de usabilidad.
  • Trata de mantenerse cerca de las expresiones idiomáticas de Django, construidas encima de las vistas basadas en clases de Django, etc ... (Mientras que TastyPie apareció antes de que existieran los CBV de Django, así que usa su propia implementación de vistas basadas en clases)
  • Me gustaría pensar que la arquitectura subyacente está muy bien construida, desacoplada, etc.

En cualquier caso, ambos son buenos. Probablemente caracterizaría a Tastypie como un conjunto sensato de incumplimientos listos para usar y el marco REST como muy bien desacoplado y flexible. Si planeas invertir mucho tiempo en la API, definitivamente recomiendo navegar a través de los documentos y la base de código de cada uno y tratar de obtener una idea de lo que más te convenga.

Obviamente, también está el ''¿Por qué TastyPie?'' sección en su LÉEME, y el ''anuncio de REST marco 2'' .

Véase también el blog de Daniel Greenfeld sobre Elección de un marco API para Django , a partir de mayo de 2012 (Vale la pena señalar que esto todavía era unos meses antes del gran lanzamiento de REST framework 2.0).

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

Última actualización feb 2014

Django-tastypie ya no es mantenido por su creador original y creó un nuevo marco 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 django y obtiene fondos para mantener django-rest-framework.

django-rest-framework también tiene un gran número de paquetes 3rd arty cada vez más grandes que te ayudarán a construir tus API más fácilmente con menos problemas.

Una parte de drf también se fusionará en django propiamente dicha.

drf proporciona más patrones y herramientas mejores que django-tastypie.

En resumen, está bien diseñado, bien mantenido, financiado, proporciona enormes aplicaciones de terceros, es confiable para organizaciones grandes, es más fácil y menos repetitivo, etc.

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

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

Vale la pena señalar que desde que esto se le preguntó por primera vez DRF ha ido viento en popa.

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

DRF tiene soporte OAuth 2 y la API navegable.

Honestamente para mí, esa última característica es el asesino. Ser capaz de apuntar a todos mis desarrolladores front-end en la API navegable cuando no están seguros de cómo funciona algo y decir ''Ir a jugar; descubrir ''es fantástico.

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

EDITAR Respuesta desactualizada, tastypie ya no se mantiene. Utilice el marco REST 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.

Yo personalmente tiendo a sabrosopie sin embargo. Parece ser más fácil de configurar. Está hecho de la misma gente que creó django-haystack cual es increíble y de acuerdo con django-packages se usa más que el framework Django REST.