tastypie - some feedback / comments

[Cal Leeming [Simplicity Media Ltd]]

Hi all,

For the last two years whenever an API has been required for a project, we have just used our own API wrapper that consists of about 50 lines, then added in the bits we needed as we go along. 

So today, I decided to spread my wings a little and give TastyPie a try... here is a bit of feedback for anyone considering TastyPie;

It works quite nicely out of the box, ties directly into the Django user models, has fairly good URL path structures, and within 30 minutes you can have it spitting out data from your models with as much control as you wish. 

However, like the django-admin system, this is where the fun ends. As soon as you want to do anything bespoke or actions that involve not fetching data (whether it be ORM or not), things start to get touchy. Attempting to get tastypie to work without a queryset/qs is damn near impossible, the uglyness of override_urls/prepend_urls() alone was enough to make me say "eww", and the general feel was overly complex.

In theory tastypie is perfect, but in practise it seems to overcomplicate things in an attempt to keep everything organized, and to quote a colleague "it has a bit too much magic". Sure, it claims to give you plenty of control to customize it for your specific use case, but the complexity of this makes actual time and sanity saved debatable.

This isn't to say that tastypie should be avoided, as it will work beautifully for simple requirements, but I personally feel that it should be kept in the same box as django-admin. It's also worth mentioning that (imo) anyone thinking about tastypie should still give it a try and see how they feel about it. It'd be interesting to hear other thoughts on it.

There are obviously some others to compare this against, the most notable being piston and Django REST framework. Although there's some bad press about piston (and I haven't tried it myself), it would probably be next in my list to try. Unlike tastypie, it treats resources as completely arbitrary objects and lets you create the magic for yourself.. so although it doesn't work out of the box quite as easily, it offers so much more benefits in the long run.

Any thoughts?

Cal

[Kurt Pruhs]

I've had the same issues. A previous developer used TastyPy for APIs and it's a nightmare trying to modify them beyond the simple, out-of-the-box functionality. In its current state, it's more trouble than it's worth.

-- 

Kurt Pruhs
Utah State University
Information Technology Department
Programming and Design Team
office: 435.797.9260
cell: 435.890.0289

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django...@googlegroups.com.
To unsubscribe from this group, send email to django-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.

[Thomas Orozco]

After giving it a try for a small personal project / curiosity, I couldn't agree more that it's great for a REST API with querysets, but whenever something doesn't exactly tie into this structure, things get complicated.

However, I would say that this can also be a good thing.

This forces you to think and build using Tastypie's principles, which I think are sane.

Eventually, this means that for an existing project, Tastypie can be a bit disheartening to use.

[sbrandt]

After evaluating some API creation frameworks, namely tastypie, pistion and django rest framework, it came out that I would never use the first two in my projects.

Sorry that I can't provide more detailed information, but it's about a year ago. Both had issues with their architecture and philosophy not being clear, straight or smart enough to me. The latter, django-rest-framework (http://pypi.python.org/pypi/djangorestframework) was very young at this time and followed the then-new paradigm of class based views. Since it behaves like other django views (URL config, mixins, etc.) it is very nice to use and extensible.

[Jani Tiainen]

> --
> You received this message because you are subscribed to the Google
> Groups "Django users" group.

> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-users/-/tXP5LkQDKXQJ.

> To post to this group, send email to django...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.

I'm also fan (and user) of django-rest-framework. Just because it's
quite easily to be extended with all kind of stuff you need (specially
since I work with ExtJS 4 which does have support that resembles REST
from some parts), allows me to define URLs I want and does quite much
stuff OOTB.

Also in few cases I really work things that do not bound to any models,
querysets or whatsoever django-rest-framework just works with them as well.

--
Jani Tiainen

- Well planned is half done and a half done has been sufficient before...