

Django REST framework 3.1 released - tomchristie
http://www.django-rest-framework.org/topics/3.1-announcement/

======
chucksmash
Super useful tool, thanks to Tom and everybody who contributes. When we began
moving some of our APIs from Django to Flask at my company,
djangorestframework was the single tool/package that I missed most. It's
lovely.

What are the plans (if any) for continued development on Flask-API?

~~~
vosper
I'm curious why you decided to move APIs from Django to Flask? We've built our
APIs on Flask, and, though I like Flask a lot, the major complaint is that
there's no real story around user authentication and authorization, endpoint
versioning, and a handful of other things that aren't directly serving the
purpose of the API, but are important nonetheless.

There are a hodge-podge of plugins to do various things, but they don't
necessarily share the same design principles or work well together. Some are
so abstracted that by the time you've got a concrete implementation you could
have just rolled your own.

EDIT: Grammar, added a sentence.

~~~
mcescalante
I am writing an API right now in Flask, and I chose it over Django never
having used Django for a REST service before.

When you say "there's no story" around auth, endpoint versioning, and other
things does that just mean that you're not forced to follow those conventions
with Flask / that Django offers utilities to help? I am a bit confused/curious
what you meant by that since I've seen some wonderful Flask auth work, and
endpoint versioning is pretty standard on most APIs, but seems like Django is
a bit more strict with what they want you to do.

~~~
tallerholler
strict in what way? I've built many api's using django-rest-framework and it
is truly awesome to work with, completely extensible and flexible and never
seems to get in my way

~~~
mcescalante
I just meant that they offer more of a base + guidelines for you to work with
when compared to Flask's "roll it yourself" approach to REST.

------
robertfw
DRF brought me back to Django after a foray into Flask-land. It's a pleasure
to work with. Thanks for your work, and to the backers who funded the latest
development!

------
bliti
@OP:

What is your long term vision for the project?

Reason I ask is due to how django keeps (IMO) gaining territory on the
corporate and/or business stack. I get requests for support and new
development consistently from companies in different markets/regions.

~~~
tomchristie
Broadly, we aiming for it to be a mature, sustainable and well-supported
general purpose Web API framework.

We tend to be fairly aggressive about keeping the scope manageable in order to
keep to that. For example 3.1 moves some functionality out into third party
packages, so that we can concentrate on the quality of the core framework.

Some of the longer term feature work:

* Admin style interface - See [https://www.kickstarter.com/projects/tomchristie/django-rest...](https://www.kickstarter.com/projects/tomchristie/django-rest-framework-3)

* Fuller support for alternative storage backends. Eg. Easier to integrate with SQLAlchemy, as an alternative to the Django ORM.

* Hypermedia support & client library. (Too involved to go into detail here.)

~~~
bliti
Thank you.

------
jnbiche
Just wanted to say that this is one of the most beautifully-documented
projects I've ever used. Bravo!

~~~
Alex3917
Agreed, although I wish there was more documentation on the benefits of each
feature, rather than just how to implement it.

E.g. there are dozens of pages on how to implement serializers, which is
great, but the section on the benefits of serializers is only a paragraph or
two long. So after reading all the documentation I'm still unclear as to the
best practices on when vs when not to use them, and what the best practices
are for endpoints that don't take advantage of them. I'm sure this kind of
stuff is obvious to people who have been using it for a while, but after just
going through the tutorial and then reading the relevant API pages I was still
unclear on a bunch of issues.

~~~
tomchristie
Thanks Alex, I think that's a great point.

Please do feel free to follow this up by raising an issue on the repository -
it'd be good to talk through some specifics about areas to improve.

------
papa_bear
Anyone have any thoughts on DRF vs Tastypie?

I've been using tastypie for the past few months in a project and I'm kindof
regretting it - I'm finding some of the design decisions hard to understand
and not super well documented. But I've gotten to the point where I'm using it
in production and it feels like it might be too big of a pain to switch at
this point.

~~~
ralmidani
I'm not an expert, but from what I've read of the docs of both projects I
understanding DRF is more modular and easier to customize with its Serializer,
Parser, View, Viewset, etc. classes than Tastypie with its monolithic Resource
class.

------
niix
Really loved this tool when I was writing Python.

------
chimmychonga
My friend and I just started getting into Django the other day. Coming from
Node.js it is a welcome change.

~~~
mendozao
what do you like about it vs node?

------
hoprocker
Has anybody used both Django REST and restless[0]? My company's starting to
migrate a Django-based system towards something more REST-full.

[0]
[http://restless.readthedocs.org/en/latest/](http://restless.readthedocs.org/en/latest/)

~~~
ballpark
I've got a little experience with both. I went full bore into DRF, and found
myself wrestling with the framework too much. I wanted to use the framework
(ModelSerializer), but found it difficult to find the hooks to customize some
behavior. Then going down a layer of abstraction felt like I had to do too
much. This is probably the reality of any framework, not necessarily the fault
of DRF.

Right now I'm using django-restless. I'm sticking with it for now. It uses
Django forms for validation, which works ok even though they weren't meant for
validating json input. Now I'm wondering if it would be best to just use
Django, and be restless in style. Perhaps DRF, restless or some other
libraries would have some pieces that I could use in a more library fashion if
I wanted them.

------
ffreitasalves
I've started using DRF last week and I don't know why I did'nt use it before.

The authentication framework and the Model serializer are really good points
to start, but I was missing some versioning scheme and 1 week later here it
comes. Great work, Tom.

------
tschellenbach
Just wanted to let you know we're a huge fan of Django Rest Framework! Thx
from getstream.io

------
hrayr
Is the upgrade path from django 1.4.18 / drf 2.4.2 relatively easy?

~~~
tomchristie
The 3.0 release notes are the place to start for looking at upgrading. They go
into quite a bit of detail about this.

------
the_vincedent
Still no M2M for ModelSerializer..? Guess I'll have to just keep using a ton
of shitty hacks.

~~~
tomchristie
Of course you can use many to many fields with ModelSerializer.

I'm not sure what you mean here, but I'd suggest opening an issue if you
believe there's a problem - we're pretty comprehensive about dealing with
incoming issues.

~~~
the_vincedent
An issue that I've consistently run into is being able to write to related
models. I can serialize them just fine, but without being able to write, it
forces users to come up with nasty work arounds. To be fair, I hate having to
write resources that handle writing nested objects, but there are some many
front end use cases where multiple writes is not ideal.

~~~
tomchristie
Oh right, writable nested serializations, sure. I won't rehash the reasons
that we don't support that in core (ill defined what behavior the user should
expect) but yeah it'd still be good to have a third party package that does a
decent "best effort" job of that.

My personal take on this is forget about "shitty hacks" or trying to handle
this automatically, and just write the serializer create and update methods
explicitly.

~~~
the_vincedent
I know why it's not supported and I agree that there should be a third party
package for it that is more or less officially supported/recommended like the
jwt package.

Most recently I created a new handler object that runs some introspection of
the model. I then override my model view sets' create and update methods to
implement the handler. Maybe I should get off my ass and open source it
(currently buried in a project).

