We're looking for a general RESTful API solution for our Django project. We would use the API at first for Ajax calls on the web site and later for mobile apps, external apps and things like that.
I found two modules which seem to be widely used. django-piston and django-tastypie
From what I read, piston seems to be older and thus more mature but maybe a bit outdated?!
While tastypie is relatively new and nicely documented.
What would be the best thing to go with? django-piston or django-tastypie?
Important for us (ordered by priority): Continuous maintenance of the source, documentation, stability, ease of use.
EDIT (2013 Jul 16th):
Now over a year later we have a clear winner. At first we went with tastypie. Which we kinda liked. But after half a year or so we switched to the then upcoming django-rest-framework and never looked back.
What we like most about it:
Nice documentation
Active community
Clean design (build upon django's class based views)
Browsable API for development and debugging
We rely on the API heavily so support (in the future) is one of our main concerns. We met the maintainer - Tom Christie - (on and offline) and he seems very committed to the project. So we feel very comfortable using the django-rest-framework.
A good resource to compare them is http://www.djangopackages.com/grids/g/api/
Django-tastypie sure is the save choice right now.
Personally I'd advocate a look at django-rest-framework if you use django 1.3, because it uses the new class based views. djangopackages.com's comparison page shows it has good participation and activity. And, wow, it sure has a nice browsable interface to the API.
I have no experience with this, but I trust Pydanny in this:
django-piston has been barely supported for nearly two years. That is
an eternity, and the number of forks to address multiple issues is a
cause for alarm. Because of that, in it's place at this time I
recommend django-tastypie. It is up-to-date, has very good
documentation, supports OAUTH, and scored second place in the Django
Packages thunderdome (it got nearly 3x as many points!). Another tool
to consider is Django Rest Framework, which is as good as
django-tastypie but lacks the OAUTH support.
On the django-piston front, Joshua Ginsberg has taken over the reins
and we should hopefully see some movement again. In which case I'll be
able to remove this section of the blog post.
from Pydanny's blog.
Having implemented API's with django Piston, tastypie and django webmachine Django tastypie rocks! Having said that, I think that while tastypie is really good when your API is modelled close to your models, it's a little bit more complicated to do things once you want to move out of the box. There are workarounds to some issues, with others you have to do more bending than building. It will, probably, still cover 90% of django use cases.
Afaik Webmachine was modelled after the popular erlang webmachine, but hasn't been very active lately. So that leaves piston, which is picking up some activity, and tastypie, that has a lot of momentum and activity. Piston is a bit more flexible, but tastypie is moving very fast and in my opinion has a really easy API.
My recommendation would be to quicky implement a prototype of the API in tastypie, and see if it covers what you want to do.
Django REST framework 2.0 was anounced in Oct 2012 and now supports OAuth out of the box. What I really like is the Web browseable API, which is really helpful when developing your API, but also when someone implements your API. It's kind of comparable with using the Django admin site for inspecting your models' structure and data, but then for your API. Also the documentation is very good.
From their website:
Django REST framework is a powerful and flexible toolkit that makes it
easy to build Web APIs.
Some reasons you might want to use REST framework:
The Web browseable API is a huge usability win for your developers.
Authentication policies including OAuth1a and OAuth2 out of the box.
Serialization that supports both ORM and non-ORM data sources.
Customizable all the way down - just use regular function-based views if you don't need the more powerful features.
Extensive documentation, and great community support.
Check out their Quickstart guide to get a quick idea of how it works.
Related
I am a nodejs developer but currently migrating to django(being a python lover). I am trying to implement OAuth2 in Django Rest Framework but I don't know how to start.
In nodejs, there is passportjs library which is well maintained, and it's got stratigies for every possible authentication type. What about django rest framework ? User name/password auth seems straightforward but oauth2 is not well covered.
In DRF docs here, It mentions two libraries for oauth. The first is django-oauth-toolkit which is well maintained but after going through docs, I didn't seem to understand much, it doesn't even talk about googl/facebook oauth. I am not sure what it is used for, anyway. The second one is django-rest-framework-social-oauth2 which seems to be straightforward but it's not been touched for over a year, it's probably not maintained any more.
So, How do you guys do oauth2 in your DRF projects ?
I hope you have solved this already. You can check my repo: It offers a simple way of authenticating against major ouath2 vendors. Here it is https://github.com/wagnerdelima/drf-social-oauth2.
You can also check my other repo https://github.com/wagnerdelima/facebook_setup. It integrates https://github.com/wagnerdelima/drf-social-oauth2 as an example to make it easy for newcomers.
Hello I am tasked with translating a current Excel tool to a web application. I decided to use Python and Django. Lately I studied the Django REST framework. I have the following related questions.
Is it for such an application a good idea to first write a web REST API so that I
firstly only need to focus on the backbone of the web application. I.e. implement the PUT, POST, GET and DELETE methods and the Django models.
The second step would be to implement the user interface... But if this is a valid method how can I reuse the REST views??? I followed the REST tutorials, but they don't show how to build a nice slick user-interface on top of the REST API.
Since REST views inherit from Django, I think it's maybe not such a good idea to write a Django view which inherits from a REST Apiview? Or can I directly use an API endpoint in a template. If so where can I get some nice examples?
Writing the back-end separately using Django REST Framework is a great idea.
There is a strong architecture based on the idea of decoupling the back-end from the front-end. After you finish the project's backbone, as you are calling it, you can start creating you front-end but your don't have to use Django template rendering in that case.
You can take the pros of using REST APIs and you can use one of the good front-end frameworks or libraries as Angular and React.js.
Another advantage of this that the same API can work with mobile development and so on.
So you develop one back-end and multiple front-ends depends on your need.
Also you can read a discussion about your question on Quora: https://www.quora.com/Why-does-it-make-sense-to-separate-front-end-from-back-end
I have recently inherited a non-finished web app written in Clojure, based on compojure and hiccup basically. It's a bad attempt to model some sort of MVC with OO style not in the FP style as seen here . So I bet to re-start the project almost from the scratch reusing the useful parts. I consider these alternatives:
The least breaking alternative would be Compojure+Enlive+jquery-pjax
Using a clojure web framework like Pedestal Any experiences about this?
The initial idea was to implement a RESTful API serving JSON so for the more elaborated solution I have Backbone+react.js in my mind for the front-end and Liberator for the back-end but it's likely to take longer to develop than a traditional server app.
Thoughts and alternatives taking into account that an Ajax experience is required please, thanks a lot!
I'm not sure what is the relation between RESTful API and responsive in your post. However ...
You have multiple options here: Pedestal, Liberator and Caribou.
If all what you need is a RESTful API, then I think Liberator is your best bet and it is not going to take longer time as you mentioned. I don't know how you got that impression.
Pedestal shines if you want to develop Single-Page applications but the framework in general requires a good time to grasp and understand how it is works.
Have a look at Caribou also. It is easy to use and feel familiar.
But again, it is your choice.
I would like to create an oauth (REST) API the same way Twitter or Foursquare does.
I found this website http://djangopackages.com/ which is really great and has several packages but I would like some opinions on which is the best package, etc...
I would like, for example, let people to allow permission to 3rd party apps to access their data (Using API Keys, etc...)
Thanks a lot!
Django is a wonderful web framework. It helpes you in many ways making rich web applications. It helps you starting in form handling and ending in templating.
However in your case if your intension is just to make an awesome API such as of Twitter or Foursquare, you have to ask yourself if you need all this help Django provides. For example, are you ever going to use any templates in the API or process a for submittions. The answer is probably not...
So if you need a very flexible framework to developer an API, I would highly recommend to take a look into Pyramid. It is very similar to Django, however does not have all this extra cludder which is not necessary for an API.
However if your application needs both a rich user interface and an API or you just want to use Django, like Ulusses suggested, then I think TastyPie is for you. It is a great library where you can have a running API in no time. I use it all the time and it is very flexible. ReadTheDocs uses tastypie.
Another API lib is piston. I haven't used it so can't judge if its better or worse then tastypie. Bitbucket however uses it.
You can check out https://github.com/toastdriven/django-tastypie or https://bitbucket.org/jespern/django-piston/wiki/Home.
You can achieve what you want with both, check out on the documentation the one that suits you best.
I use Django REST framework. It is awesome.
Piston is dead. Tastypie is awesone, but works with Django only. There are pros and cons with Django as well as Pyramid. If you need great ORM, sqlalchemy is only one, and there is no good example of using it with Django, so in this case you have Flask, Bottle or Pyramid. Django ORM is really not at that par.
If you choose Pyramid, you will have to write a lot of things, and the framework is just skinned boneless cat. You need to assemble and configure every block, seems frustrating to many including me.
Guys i would like to use Django as my backend framework and qooxdoo as the frontend framework.
Is it practical to do this?
Has anyone tried to do this?
How did they do it?
Links and pointers would nice.
Gath
I have no direct experience using Django and qooxdoo, but the general answer to the question "Is it practical?" is: yes :). Although Django's default rendering behaviour is to produce HTML (which is unsuitable for a single page application like the ones you build with qooxdoo), it's easy to switch to returning e.g. Json on requests, which is a common format for the client-server communication between a qooxdoo frontend and a server. They just exchange data.
Has anyone tried to do this? - Yes, but they don't give much information on how, other than the before mentioned Json data exchange, implementing a Json RPC server in Django using RPC4Django.
AFAIK, there is no deeper Django integration, e.g. interfacing qooxdoo with Django views on the server (like dojango).
Hope this helps.
Update:
There is one elaborate product, Sava, using qooxdoo for the frontend and Django for the backend. There is a short overview, but I think it's closed-source so it only testifies to the "practicality" of using this technology stack. You probably won't learn in detail how it is realized.
There is also enre, a qooxdoo-based GUI for Django. But I'm not familiar with it, and couldn't find any documentation on first glance, so I'm not sure what this really means.