I've never understood why people like this framework so much. It's not that flexible. If you want to customize your API in specific ways ( ordering, nested resources, validation ), then you will undoubtedly just write your own CBV(s).
After writing your own CBV(s) for awhile, you will either love that solution or hate it and look for something more flexible and out-of-the-box.
For many of the things that Django REST framework version 3 is attempting to solve there is already an awesome alternative to it and TastyPie called Conduit. I highly recommend people give it a shot, since it's pretty modular. It also presents a different alternative to Function and Class-Based views:
Django Rest Framework for us - http://ansible.com - was easier to customize and also easier to graft in custom auth. One of the major tastiepie problems we had - that maybe everybody doesn't have, was how to be able to make collections hang off REST resources.
The greatest feature by far is the API browser, which in DJRF 2 (I have no sense of what's in the 3rd version) is pretty amazing and a great way for people to learn about an API.
Less automagic made it much more flexible for us, while the API browser is just amazing in a end-user demo. It's my favorite feature, though I also like the serializer system.
Been writing a Django-based API-heavy app and it still feels very Django. DRF fits the ORM like a glove and there's a Django way of doing things that runs throughout. Models ≈ ModelForms ≈ ModelSerializers ≈ ViewSets ≈ ModelAdmin. Certainly never feels like I'm fighting the framework(s).
Good point, but my impression of this tool is that it's more intended for quickly tacking an external API onto an existing Django app, and not so much for building an internal API for a client-side MVC app (Angular/Ember/Backbone etc). It can certainly be used for that too, but Django is kind of overkill for that use case, and a lighter-weight framework like Flask with a REST plugin like Restless and (optionally) an ORM plugin like SQLAlchemy is probably sufficient.
My thought too but if your data is complex you should consider building an API first using an ORM more powerful than Django's (e.g. SQLAlchemy) then use Django to handle users and then allow your users to access the API directly via signed requests or something... that way you get good performance without network/Django ORM overhead.
I prefer SQLAlchemy, but it definitely has just as much overhead as django's ORM. This is just a microbenchmark, but notice how when frameworks are making raw DB queries they stomp the ones using ORM:
Looking at only python frameworks using ORM, Flask with SQLA hits 85% of the requests/sec of Django using pypy, and only 73% on stock python. Django has decently lower latency as well (450ms django, 550ms flask pypy, 600ms flask stock python):
Really, if performance matters at all and you want an ORM use Java. The fastest python solution using an ORM is a tenth as fast as the Java solutions, with literally 10x the latency. :P Flask making raw db queries gets within 2x of this, as does bottle.
These numbers are somewhat misleading, and the phrasing may confuse people.
> The fastest python solution using an ORM is a tenth as fast as the Java solutions
This may be true if your bottleneck is the ORM in the first place (this is relatively easily verifiable by running a profiler on your python program, comparing the results against (e.g.) EXPLAIN ANALYZE output, etc.)
I run a service with a decently-sized database (over 100G); so far all the bottlenecks were at the "query execution in the DB" level. I use lower-level SQLAlchemy primitives to form the queries, and check the resulting raw SQL against the raw SQL queries that I had designed for the DB before. If you know what you're doing, SQLAlchemy will know, too.
Use cases and situations vary. But the way you phrase those particular benchmarking results is somewhat misleading.
I wasn't refering to performance, but the queries you could do. If performance was an issue and the ORM was the bottle neck then I would use raw SQL and scrap the ORM altogether. Thanks for this benchmarks though good to know that info! :)
Edit: The overhead thing was a secondary point my main point was handling data.
Depends on your data, if you don't need joins/complex queries Django indeed is a great framework, though if an API is all you need a lighter framework might be worth looking into.
Django's ORM seems to be one of the areas they're consistently improving upon. Sure it's not SQLAlchemy. But SQLAlchemy is just an ORM, while Django is quite a bit more. Though I really love how SQLAlchemy separates it's core from the higher-level ORM.
Looks interesting, might port one of my tastypie projects to it.
However I'm very concerned about the author's inactivity. Tastypie has gone unmaintained several times for a long time. It looks like restless is headed that way as well. Concerning.
After writing your own CBV(s) for awhile, you will either love that solution or hate it and look for something more flexible and out-of-the-box.
For many of the things that Django REST framework version 3 is attempting to solve there is already an awesome alternative to it and TastyPie called Conduit. I highly recommend people give it a shot, since it's pretty modular. It also presents a different alternative to Function and Class-Based views:
http://django-conduit.readthedocs.org/en/latest/