Django REST framework 3.4 Released | Hacker News Reader

Django REST framework 3.4 Released

django-rest-framework.org

278 pointstomchristie87 comments

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.

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

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

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...

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

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

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

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...

Its pretty similar from developer perspective.

That doc is dated 2010. Further proof docs lie ;)

But as other people said, no idea if it was copied and pasted into the django codebase or rewritten from scratch.. but everything South did, I believe Django now does.

Rewritten by the author of South. Basically, all the good ideas of South with some of the problems fixed.

The new Django Migrations from 1.7 are heavily influenced by the south project, but are slightly different.

I believe that both the Django Core team and Tom Christie (DRF author) have stated that they have no desire to see DRF brought into Django, as that would tie DRF updates to Django updates, which would potentially slow down DRF releases.

makes sense.

Django is Python's killer app, and DRF is Django's killer app.

I think versatility and the absolutely easy on-ramp are Python's killer app. The 'absolute noob' can start writing simple python code after 5min of introduction (you can start using it like BASIC), while the 'senior dev' can still write python after years and isn't turned off or overly constrained by the language. (Yes, of course, warts exists, no language is perfect)

And regarding Django being the killer app: There are other people for which numpy/scipy is Python's killer app, for example.

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.

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

Does faster mean speed of development or speed of code execution?

Speed of development I guess.

Speed of development.

For the vast majority of APIs, the limiting constraint on responsiveness is not code execution but your database.

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/

DRF is not the same as Django, fwiw.

Since you're looking for an alternative to RoR, I'm assuming you want Django. They have great docs and you might check out godjango.com

If you want to focus on REST APIs with Django, DRF is pretty much required, and it's only a "pip3 install" away.

I flirted with switching to Rails (and did a lot of Code School courses and most of Michael Hart's Rails Tutorial), then realized I didn't have to limit myself to what comes with Django out-of-the-box.

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

ugh that'd be great sans angularjs

Yeah. For that you should try Realpython [0]. Minimal but best. [0] https://realpython.com/blog/python/django-rest-framework-qui...

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

I learned it recently, the best tutorial on Django is right in the docs. The docs start you off with a tutorial for building a polling app that is really great for teaching the basics

https://docs.djangoproject.com/en/1.9/

The docs are amazing, probably because Django was created by journalists so they are really great at communicating things. It's not like most programming docs that leave you feeling lost and need to be supplemented with outside tutorials.

That said I'm new to programming so I supplemented the tutorial and instructions on the docs page with the one on the Django girls site.

http://tutorial.djangogirls.org/

I found that between these two and occasional references to stacks when I felt lost, it was all I needed.

'Tango with Django' is by far the best tutorial on Django that I've found (http://www.tangowithdjango.com/). It is well written and goes much deeper than other tutorials. It's depth is similar to the Rails Tutorial in RoR world.

Actually, DRF itself has a fairly comprehensive tutorial. You linked to the "quickstart" page, but if you click on the other tutorial links it goes into much greater depth.

For example, the first page of the "real" tutorial covers serialization in depth: http://www.django-rest-framework.org/tutorial/1-serializatio...

I really wish there was a JS framework with the elegant API and built-in functionality of Django+DRF.

The way models, serializers, and viewsets are defined and work together is, AFAIK, non-existent in the JS world.

Even Ember, which IMO is the best candidate for becoming a full-stack framework, does not have all the bells and whistles that come with Django's ORM.

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?

Closest things I know of are:

* Ruby Together - https://rubytogether.org/

* Django Fellowship Program - https://www.djangoproject.com/fundraising/

* Read the Docs sponsorships - 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.

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.

There was a port of DRF for Flask, but it was not as mature and not as good. I went with Django mainly because of the included batteries and in particular DRF.

I was just always dissuaded from the size of Django, Flask is mininal, and gets up and running quicker for me. Coming from a lot of Express work, it just made more sense to me, but I'll be definitely diving into DRF for my new project.

Django is batteries-included, but the batteries aren't heavy. You can easily turn off 99% of the stuff it does for you.

You also never know when you need a really good admin panel.

The admin is great, especially at the start of a project, when you want to look at and manipulate your data even if it isn't needed in the product you end up with.

The size is less relevant - you only use what you need. The other main reason I chose Django for a particular project is the ease at which I can find experienced developers afterwards. Not that it really matters that much, Python being Python, but its easier to find someone with Django experience than one with Flask.

But django is a superset of Flask. If it's easy to find django devs it must be easy to find Flask devs.

Not really. Because its python, its all Python devs. But if you want someone with specific Django experience, you'll find it easier to find than flask. Popularity wins and Django is popular (for a good reason)

I use flask for a few applications.. it works, but even in my cases:

Any sufficiently complicated flask application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of django.

For sites that are just a few endpoints, it's great. I use it on an application that uses redis+gearman to spawn docker containers on demand. django would have worked too, but I'm not using anything other than routing and templating.

On the other hand, I have an application that I built on flask that I needed to shift the timezone of the dates.

in django you change TIME_ZONE and you're done. My flask app I had to fix it all myself, it was a nightmare.

Django can be minimal if you want: https://github.com/rnevius/minimal-django/blob/master/minima...

The size of the framework is really not relevant in the context of Python server-side development. You just import what you need and ignore what you don't.

For example, I develop single-page apps with Django+DRF and Ember, so I never use Django's template engine. If you really want to minimize your setup, you can even go into your settings.py file and turn off the middleware you don't need.

Put another way, it's not like client-side JavaScript where the entire framework is sent to the user's browser.

Beware, having used Django, Pyramid, and Flask (in order of first use) I would highly recommend Flask over Django. Django is batteries included which can cause pain when trying to use different batteries. For me, SQL Alchemy > Django ORM for example.

But if your use case fits well within the Django ecosystem...then Django can be easier.

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-...

Yeh that's neat, but I feel like that is just going to cost me something to play. Also, there will be other databases tied into this project as well SQL Server, MySQL, and RethinkDB.

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).

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

As the author, yes.

The team I was previously with used Core API in some of 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.

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.

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

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.

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?

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?

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

Then don't sweat it! :)

I did fund your original kickstarter for DRF3 as a heavy DRF user at $job, and now might consider signing up as a recurring payment. Your code has saved me a lot of time and effort in my career, so thanks much sir!

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.

"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.

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.

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

You can also use the include(x.urls) feature to really simulate nested routes.

http://www.django-rest-framework.org/api-guide/routers/#drf-...

See for yourself.

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.

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.

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.

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.

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.

I've used https://github.com/alanjds/drf-nested-routers with success.

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!

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

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

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.

IMHO, the concept makes a lot of sense. They're basically just more generalized forms.

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.

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/ 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 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

Standard DRF is nothing like the JSON API spec.

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

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?

Smells really nice [1]

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

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.

How does it compare to Code Igniter from 10000 feet?

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

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...

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.

Reply on news.ycombinator.com