
Django REST framework 3.4 Released - tomchristie
http://www.django-rest-framework.org/topics/3.4-announcement/
======
agconti
Its really awesome that this project continues to endure. The code base is top
notch and the maintainers are committed to the highest level of quality.

DRF is one of the core reasons why Django is top choice among web frameworks
today. In my opinion, it sets the standard for rest frameworks for the
development community at large.

~~~
davesque
Agreed, this is a top notch project. Excellent code, documentation and, above
all, the concepts exhibited in the library are extremely well thought out.

~~~
guscost
To be perfectly honest I think the implementation is a lot better than some of
the documentation. The tutorials can be pretty confusing or just plain broken
for anyone without at least an intermediate proficiency in Django already.
Perhaps the documentation should have messages recommending that developers
get good at Django first.

Most of my experience with it has been great though, it's a very well built
technology.

For a helpful reference also check out [http://cdrf.co](http://cdrf.co)

~~~
mixinspy
Agreed! The code is lot easier to read than the docs. I generally think of DRF
as "that which has to be true so that mixins.py[1] makes sense"

1- [https://github.com/tomchristie/django-rest-
framework/blob/ma...](https://github.com/tomchristie/django-rest-
framework/blob/master/rest_framework/mixins.py)

------
timc3
Django REST framework really makes Django in my opinion. It really is the add-
on which opens up a lot of possibilities.

~~~
misiti3780
agreed - maybe it will be integrated into django someday like south was

~~~
morenoh149
was south integrated? the docs say it hasn't
[http://south.readthedocs.io/en/latest/about.html#a-brief-
his...](http://south.readthedocs.io/en/latest/about.html#a-brief-history) but
maybe it's outdated?

~~~
themoonbus
The main developer of south was responsible for bringing schema migrations to
Django's core... don't know how similar it was to south's codebase, though:
[https://www.djangoproject.com/weblog/2013/mar/22/kickstartin...](https://www.djangoproject.com/weblog/2013/mar/22/kickstarting-
schema-migrations-django/)

~~~
collyw
Its pretty similar from developer perspective.

------
Alex3917
I'm really glad that ModelSerializer classes now require either fields or
exclude. IMHO not requiring that before was one of the biggest weaknesses of
the project, since it could easily lead to data being unintentionally exposed.

I know that's maybe not the most exciting change, but I think it's important
that it be very obvious what the code does even if a person isn't an expert in
a given technology, especially when there are privacy/security implications.

------
morgante
I love DRF. Compared to building APIs using Flask or Node, it's an order of
magnitude faster.

~~~
Abundnce10
I love Python but I've never used Django -- I've always used Ruby on Rails
since that's what I'm familiar with. Do you know of any resources I could use
to get more comfortable with DRF (i.e. more complex than just the Quickstart
tutorial [0])?

[0] [http://www.django-rest-
framework.org/tutorial/quickstart/](http://www.django-rest-
framework.org/tutorial/quickstart/)

~~~
babayega2
I always recommend the tutorial [0] from Thinkster where you have to build a
clone of G+ using Django ( DRF) and AngularJs. Try it. It's fun.

[0] [https://thinkster.io/django-angularjs-
tutorial](https://thinkster.io/django-angularjs-tutorial)

~~~
morenoh149
ugh that'd be great sans angularjs

~~~
ericmsimons
We have a pure DRF tutorial coming out on Thinkster in ~2 weeks, so stay
tuned!

------
paukiatwee
Out of topic, I think the way DRF project funded is very interesting, i.e.
public funded fulltime developer working on OSS. How many other similar
successful OSS with such funding?

~~~
tomchristie
Closest things I know of are:

* Ruby Together - [https://rubytogether.org/](https://rubytogether.org/)

* Django Fellowship Program - [https://www.djangoproject.com/fundraising/](https://www.djangoproject.com/fundraising/)

* Read the Docs sponsorships - [http://read-the-docs.readthedocs.io/en/latest/sponsors.html](http://read-the-docs.readthedocs.io/en/latest/sponsors.html)

I think the business case is clear enough to make for a big project like REST
framework. It's a relatively small investment per-company, but the relative
payoff _if_ we can hit a level that keeps it sustainable is huge.

------
overcast
Interesting, somehow this project didn't come onto my radar. I was just about
to start using Flask to build a REST API for our Oracle database. Definitely
checking this out instead.

~~~
thorin
If you have oracle would you consider using Oracle rest data services? I've
only used it a little bit but it seems to make everything very easy.

[http://www.oracle.com/technetwork/developer-tools/rest-
data-...](http://www.oracle.com/technetwork/developer-tools/rest-data-
services/overview/index.html)

~~~
emmelaich
I've installed ORDS. It's got some installer wackiness -- modifies the .war as
part of the install.

Otherwise, it's smooth enough and runs in Tomcat.

I haven't used the REST features so much; we just use for the APEX pl/sql
bridge (ugh).

------
tbarbugli
Very interesting new feature, anyone has already some experience with the Core
API implementation of DRF?

~~~
tomchristie
As the author, yes.

The team I was previously with used Core API in some of
[https://www.crunchboards.com/](https://www.crunchboards.com/)

That's got a service-based architecture, and we were using it both on the
server side (where we wrote explicit Core API schemes, rather than auto-
generated) and on the client side (moving towards doing our inter-service
communication using `coreapi`, rather than directly through `requests`.)

For us, the dynamic client libraries were a big win - the client code that
you're working with becomes more meaningful and robust, as it's working with
an application layer abstraction, rather than directly at a network layer.

------
criloz2
I really love the django ORM, after your model are done you can create a
really fast api with DRF, and if you want to try graphql/relay is possible
with graphene [https://github.com/graphql-
python/graphene](https://github.com/graphql-python/graphene).

------
orliesaurus
DRF has some of the best docs for building APIs in Python - thanks for keep it
real!

~~~
mrweasel
The documentation is great, but navigating it is a pain. Class names, methods
and modules really should be links to where they are documented (because they
are almost always documented). Search could also stand to improve, a lot.

------
dopeboy
Big fan of DRF. Great documentation and awesome support on the usual channels.
I use it for all my greenfield projects.

I can't find a way to make a one time donation. Anyone know how?

~~~
tomchristie
That's not currently supported. We need recurring revenue rather than one-
offs, so that's what I'm pushing for right now. Out of interest, is recurring
something you'd consider if there was another lower-priced individual tier
added?

~~~
dopeboy
Totally understandable. I wouldn't just because my budget is very tight now.

~~~
tomchristie
Then don't sweat it! :)

------
eljulio
Well Django is good for ORM, migration and admin. DRF gave a new opportunity
to provide new web technology to this old framework but it's not enough. The
global stack is very heavy and it's very complicated to use Websocket. I was
fan of Django but for me the future is in framework like phienix: light stack,
fast, secured and supporting current web technology. It's avoid you all the
time loose to implement tornado/rabbitmq stuff.

~~~
kennydude
"global stack is very heavy" is quite subjective, when a lot of what it
provides you generally need or end up writing yourself

Django Channels is coming in 1.10 which will make realtime better.

------
sandGorgon
my only blocker for migrating a legacy application to DRF is because it doesnt
have support for nested routes (and I have to use a third party package).

AFAIK this is deliberate and opinionated.

~~~
morgante
What do you mean by nested routes? You can definitely have an API which looks
like this: /api/people/morgante/comments/3000/

~~~
sandGorgon
[http://www.django-rest-framework.org/api-
guide/routers/#drf-...](http://www.django-rest-framework.org/api-
guide/routers/#drf-nested-routers)

See for yourself.

~~~
morgante
I'm not sure why that would prevent you from migrating to DRF. It's clearly
supported and there's even a helper module to nested routes even easier.

~~~
sandGorgon
I'm not really sure why a framework would take a position where something is
important (and probably requested enough) to put it in the official
documentation.... but not make it part of the core.

I fear we-barely-tolerate-it syndrome.

~~~
morgante
It's entirely possible to do in core without any extensions. It seems like
you're just coming up with ridiculous excuses to not use DRF.

~~~
sandGorgon
I'm willing to learn. I don't understand why you term it as "ridiculous", when
the official documentation points to an external package.

Is the documentation wrong ? If there's another way...why does it not get
mention there?

From my perspective, this is weird.

~~~
morgante
First of all, why can't you use an external package?

If all you want is URLs which look like "/api/people/morgante/comments/3000/"
it's easy enough to construct those simply as standard viewsets. They're
totally normal.

------
tschellenbach
Every time I build something using a different stack than Python/Django I feel
a bit sad I can't use DRF :)

Awesome project, we're supporters!

------
mpicard
Wow dynamic client libraries, holy crap I'm mind blown I can throw out my thin
requests wrapper and never maintain it again.

------
Kiro
So I went and had a look at the quickstart and the first thing it talked about
was serializers. Why is that even necessary?

~~~
asimuvPR
Because they are a core component of the library. Its a big part of the
utility it offers. They assume someone looking to use it already knows enough
django basics.

------
bsbechtel
Just curious if someone could give the tldr version of this vs graphql. I'm
familiar with django, but not the rest framework, and have a basic
understanding of graphql but am not really sure how they compare.

~~~
morenoh149
This has very little to do with graphql. The DRF is to get a solid json api up
and running quickly. The standard it ships with conforms to the
[http://jsonapi.org/](http://jsonapi.org/) spec. Which came mostly from the
Rails community and many projects built in different stacks conform to.

If you're familiar with Rails it's like [https://github.com/rails-api/rails-
api](https://github.com/rails-api/rails-api) which was recently merged into
Rails in v5.

You could totally add a graphql endpoint to any api `/graphql?[your GQL query
here]`. We're currently exploring adding that to our Django/DRF backend with
one of these [https://github.com/chentsulin/awesome-graphql#lib-
py](https://github.com/chentsulin/awesome-graphql#lib-py)

~~~
cdrx
Standard DRF is nothing like the JSON API spec.

~~~
morenoh149
This is true. My mistake. At our company we added [https://github.com/django-
json-api/django-rest-framework-jso...](https://github.com/django-json-
api/django-rest-framework-json-api) to get DRF conformant to jsonapi spec.

------
ralmidani
I've been thinking about a new acronym for a web development stack.

I build my apps on GNU/Linux, deploy via Apache, and use Django (with DRF) and
Ember.

So how does "GLADE stack" sound?

~~~
niftich
Smells really nice [1]

[1] [https://www.glade.com/en/fragrances](https://www.glade.com/en/fragrances)

~~~
ralmidani
Infringing on a registered trademark was not my intent.

But if you think about it, such a stack should reduce the amount of stink in
Web development.

------
MrBra
How does it compare to Code Igniter from 10000 feet?

------
cdnsteve
Would DRF ever be an official third-party library like Channels is going to
be?

~~~
mikeokner
Possible, but the maintainer has stated there aren't plans to completely merge
it into Django proper.

[https://www.reddit.com/r/django/comments/2ijyuq/added_tom_ch...](https://www.reddit.com/r/django/comments/2ijyuq/added_tom_christie_to_core_team/)

~~~
zentrus
This is true, and I love DRF but I find it unfortunate then that the concept
of Serializer exists. Tom Christie essentially says that Serializers can and
should be used outside of views (REST) to decouple and encapsulate business
logic. He seems to believe models are database operations-only. This view is
fine (e.g., data mapper) but then it seems the scope of DRF is beyond REST and
should be part of core.

