

REST framework 2 released: Simple, beautiful, browsable Web APIs for Django - tomchristie
http://django-rest-framework.org/topics/rest-framework-2-announcement.html

======
senko
Not happy with Tastypie[0] or DRF[1], we've created another one, basically a
simple wrapper around CBVs, for a specific niche (RESTful but not HATEOAS,
JSON-only): <https://github.com/dobarkod/django-restless> (overview&docs at
<http://django-restless.readthedocs.org/en/latest/> )

So far used it in a couple of our projects, but would welcome feedback.

[0] too much ModelResource magic [1] custom model (de)serialization into
multiple formats, browsable api is majority of the framework: IAGNI, and 80%
functionality we needed was in 20% of DRF (which is basically what Restless
is)

------
dbrgn
As Tastypie has already been mentioned, and as it's probably REST Framework
2's main competitor – how do the two compare?

------
jarcoal
I just released a small REST API framework for Django as well:
<https://github.com/jarcoal/django-sliver>

It's built entirely on CBVs, so if you're familiar with them, you will feel
right at home.

The API is not frozen, so it's not production ready yet.

------
tomchristie
Note that there's a live version of the tutorial project available for testing
here: <http://restframework.herokuapp.com/>

------
samwilliams
Any chance we can add 'Django' to the front of the title please? 'REST
framework 2 released' is a little misleading. The article is titled 'Django
REST framework 2' any, so it would be more consistent anyway.

------
aidos
This one is close to my heart at the moment. I'm not a big fan of Django in
general as it's just too heavy for my needs but I've tried all the rest libs
to try to get something that works for me. I haven't been completely happy
with any of them.

So far the closet to happy I've been is with flask-restless - though I'm busy
hacking around with that to get it working how I need (it's pretty feature
light). It does mean I get to use SQL-Alchemy, which is every different kind
of nice.

There's no doubt, designing a powerful and flexible api framework is a
challenging job.

Will have a look at this now too, though. I'd definitely rather use something
that has some development resource behind it instead of rolling my own.

------
bruth
I too wrote a REST app for Django <http://bruth.github.com/restlib2/>. I took
the approach (which I speak about in the "Why?" section) to simply use the API
terminologies HTTP already provides. Too many abstractions is a bad idea. For
the curious, I've heavily documented Resources class:
[https://github.com/bruth/restlib2/blob/master/restlib2/resou...](https://github.com/bruth/restlib2/blob/master/restlib2/resources.py)
I've used it in production for quite some down now, but it is not yet
complete.

------
klibertp
I recently discovered REST framework for Python and... Twisted! It's so cute,
I couldn't resist and actually used it to write a proxy for Google Refine
reconciliation and url fetching functionality (for speedup and easier data
manipulation) and it worked. Worked very well! Here it is for those
interested: <http://pypi.python.org/pypi/CorePost/0.0.16>

------
goronbjorn
I still think Flask a much better choice for RESTful APIs when it comes to
Python. It's a lot more lightweight, and companies like Twilio have done a lot
to make building APIs with Flask very easy: <http://flask-
restful.readthedocs.org/en/latest/>

------
almost
A very much needed add-on for Django. It's cool to see the amount of work
that's been put into making version 2 great!

------
madrox
We use DRF 1 for all our APIs. Very excited to give DRF 2 a whirl.

------
CoffeeDregs
OT?: I wish the tutorial were better. It starts out with maximum complexity
(minimal usage of the framework) and then reduces complexity. I skipped to the
last page to try to see if DRF would actually save me time.

Compare to TastyPie where a functional API is built with very few lines of
code and right near the top of the tutorial: [http://django-
tastypie.readthedocs.org/en/latest/tutorial.ht...](http://django-
tastypie.readthedocs.org/en/latest/tutorial.html)

~~~
jeromeparadis
Personally, I like the approach of the tutorial.

It starts with the amount of code you would usually write if you were to write
an API by hand and then simplifies things along the road. At the end it makes
it clear how the framework can be simple to use while you've learned how to
use it behind the hood if the magic needs tweaking.

------
ppadron
If you need to stick with Ruby for whatever reason, I recommend using Grape.

<https://github.com/intridea/grape>

------
juaninfinitelop
Since everyone is sharing the django-rest framework they are using, I'll chime
in with my choice:

Django-Piston

<https://bitbucket.org/jespern/django-piston/wiki/Home>

I have not used any other frameworks but will be trying ops suggestion.

~~~
vaf
Django-Piston is not longer being worked on. It may be risky to use a tool
that isn't being regularly maintained.

------
albedoa
"Most people just make the mistake that it should be simple to design simple
things. In reality, the effort required to design something is inversely
proportional to the simplicity of the result."

Sort of off-topic, but did Mr. Fielding mean to say either "inversely
proportional to the complexity" or "proportional to the simplicity"? This
quote implies that as effort increases, simplicity decreases, which seems out
of spirit with the context of the quote.

~~~
njharman
No. Simple things are hard to create.

~~~
albedoa
Yes, we understand what he means to say, but his words say the opposite.

He meant to say: "As effort increases, simplicity increases."

He instead said: "As effort increases, simplicity decreases."

------
jtchang
How easy is it for me to upgrade? I have been using Django REST framework for
a while and this upgrade path seems scary. I looked at the migration guide but
it doesn't say anything about what I should be specifically concerned with.

~~~
tomchristie
There's so much work has gone into REST framework 2 that it's hard to present
a single definitive migration guide. Best way to get an idea of migration plan
would be to work your way through the tutorial first to get an idea of how
everything fits together. You will need to put a little bit of work in, but
it'll be time very well spent. Any questions at all just head over to
[https://groups.google.com/forum/?fromgroups#!forum/django-
re...](https://groups.google.com/forum/?fromgroups#!forum/django-rest-
framework) or try #restframework on freenode IRC.

------
togasystems
How easy would it be to hook this up to some sort of authentication scheme
such as OAuth?

~~~
tomchristie
Pretty trivial. I'm planning on having integration with django-oauth2-provider
added any day now.

Here's the outstanding ticket for OAuth:
[https://github.com/tomchristie/django-rest-
framework/issues/...](https://github.com/tomchristie/django-rest-
framework/issues/8) There's a link to a gist on there which implements that
for REST framework 0.4, which just needs a little updating, testing, and
documentation.

------
megaman821
This looks pretty good. I like that it leverages Django's CBVs. I couldn't
tell from the docs if you could do queryset filtering though the URL's
querystring (e.g <http://api.example.com/blogs?author=10>).

~~~
tomchristie
If using the generic CBVs you can override .get_queryset() to implement
filtering just as you would with regular Django CBVs.

There's also an outstanding pull req to build in support for django-filter and
other filtering backends which now just needs some docs, and which I plan to
have merged in within the next few days or so.
[https://github.com/tomchristie/django-rest-
framework/pull/29...](https://github.com/tomchristie/django-rest-
framework/pull/290) That'll make it easier to do more complex filtering stuff.
(And eventually have the filters be presented in the Browsable API)

~~~
megaman821
I have a mixin that often use to do basic querystring filtering with CBVs, but
it is nowhere near as comprehensive as [http://django-
tastypie.readthedocs.org/en/latest/resources.h...](http://django-
tastypie.readthedocs.org/en/latest/resources.html#basic-filtering).

------
bmelton
I'm fairly entrenched with Tastypie at the moment, but I've always been
jealous of REST Framework's "document at the endpoint" setup.

Can I ask how you're determining whether or not the client is making an API
call vs visiting the page directly? It'd be great to be able to supply
Document templates that surface like REST Framework does, but I can't make out
whether you're checking the client, the action, the protocol or something
altogether different.

~~~
tomchristie
It uses the client's 'Accept:' header which specifies which media types it
prefers for the response (eg. 'text/html', 'application/json')

Browsers will indicate that they prefer HTML, so that's what REST framework
serves them.

~~~
bmelton
So obvious, I'm embarrassed I didn't think of it first.

Much thanks!

------
camus
Aren't Class based views "restfull" in Django 1.5 ?

~~~
almost
They provide some things that are useful for certain aspects of RESTfulness.
Mainly making it easier to support the HTTP verbs properly, that's a very far
from all there is to RESTful things though and that's where something like
Django REST Framework comes in...

------
zerop
One newbie question: Why do I need a REST framework? I am able to create
get/post APIs with what django offers. What would I need REST frameworks for
django?

~~~
bmelton
A couple of reasons I switched to entirely REST-based apps:

In case you want to provide an API to other users who aren't going to be
making native Django calls.

In case your app is going to be based on Backbone (which maps models endpoints
to REST endpoints, to oversimplify things.)

In case you need to consume your app from a mobile app, or external site, or
whatever.

In case you want to surface your data in any way without having to give
read/write access to the database directly -- you can implement REST and API
Token authentication that maps to users so that they can read and write to the
data that they have access to, but no more.

~~~
reddit_clone
>API Token authentication

Could you give some pointers/links about how this is done?

I have used REST internally with no authentication. But I am not sure how
these can be exposed to outside in a secure manner.

~~~
bmelton
If you wanted to restrict all API access to only logged-in users (to your
Django app), it would be as easy as this:

    
    
      from tastypie.authorization import DjangoAuthorization
    

and then in your 'Meta' class for each resource, you'd specify the following:

    
    
      authorization = DjangoAuthorization()
    

That's step one. To go further, and limit access to resources per user, so
that they can only access the things they should have access to (according to
Django permissions), you'd simply use 'apply_authorization_limits' to narrow
the query object to what the user should have access to. So, if your default
query looks like

    
    
      queryset = Resource.objects.all()
    

You could filter that down in your apply_authorization_limits method to
something like this:

    
    
      def apply_authorization_limits(self, request, object_list):
        object_list.filter(user=request.user)

------
misiti3780
Any chance any of these REST libs are going to support mongodb? If one already
does, can someone provide a reference?

~~~
tomchristie
REST framework's serialization isn't tied to the ORM, so it should play
perfectly well with mongodb.

------
vital101
If you're looking for a framework for creating REST APIs in Django, TastyPie
is also worth a look.

<https://github.com/toastdriven/django-tastypie>

~~~
dev360
+1. We started with django rest framework and it was a disaster.

The class-based approach gave very little practical reuse, and it was not
granular enough to allow us to easily add validation rules or customize the
fields to return from a model. Lots of ugly code where you had to concern
yourself with response codes.. I mean whats the point with a framework if you
have to concern yourself with response codes? Isn't it the frameworks role to
abstract away these details?

Most of my beef with the framework has to do with the design. It has
abstraction in all the wrong places ... Inversion of Control (IoC) just seem
like a complete afterthought in the entire design.

Now with Tastypie, I will admit it has a steep learning curve, and a
conceptual overhead, but it does a much better job of abstracting away the
internals and you end up with a much more correct and consistent REST
implementation. In addition, it is better architected which makes it easier to
extract base classes and override behavior, which is valuable if you need it
to work really well with non DB models.

I will say that deep down I'm not really happy with either alternatives
though. Tastypie requires too much code to get up and running and it takes too
much time to get confident with it. Will def. take a look at the other
frameworks mentioned in this discussion.

~~~
tomchristie
Seriously, take a look a 2.0 - it's a huge, huge step up from the previous
version, practically every aspect has been reworked and redesigned.

The initial version made some design compromises in order to support the
Browseable API, and didn't take full advantage of Django's generic CBV's.
(Since it was released when Django was still at 1.2) REST framework 2 fixes
all that and much, much more.

I'd throughly recommend spending a while walking through the tutorial and
taking a browse around the docs - I think you'll be pleasantly surprised.

~~~
dev360
Thanks - I'll take another look on the next project and see how it compares

