5 ms·

The main REST framework options for Django seem to be: * Piston (https://bitbucket.org/jespern/django-piston/ https://bitbucket.org/jespern/django-piston/) *

by po 15y ago

The main REST framework options for Django seem to be: * Piston (https://bitbucket.org/jespern/django-piston/ https://bitbucket.org/jespern/django-piston/) * Tastiepie (http://toastdriven.github.com/django-tastypie/ http://toastdriven.github.com/django-tastypie/) * django-rest-framework (http://django-rest-framework.org/ http://django-rest-framework.org/) * Web Machine (https://github.com/benoitc/dj-webmachine https://github.com/benoitc/dj-webmachine) * Dagny (https://github.com/zacharyvoase/dagny https://github.com/zacharyvoase/dagny) * Roll your own (surprisingly common since it's not too hard) I think it's great that there are so many options but it's starting to get bewildering. I think part of the reason for this is how un-restful the default django routing/view technique is. The code samples in the Django documentation don't exactly start beginners down the right track the way other web frameworks do. You can do it the right way, but it requires a fair amount of discipline. I've been toying with replacing all of my django routing/views with a framework (or at least a pattern) that encourages more restful design.

bad_user 15y ago
There are so many alternatives because most of them suck. I've had the misfortune of choosing Piston for a production app. The API broke several times, not to mention the version I'm using which is fairly recent is still having problems rendering the documentation (triggers a weird error and then server requires a restart). Also, automated documentation is NOT a feature you want, it's just something on which devs waist time - it sounds well in practice, until you discover Sphinx. Sphinx does a better job in a more generic way. I don't get it why people reinvent the wheel. Django's routing is fine IMHO and you can always write your own magic decorators or classes to add on top and it's not that hard to do. Django's problem is that it doesn't provide guidance on what goes where and how. Even the standard project structure that's first created by django-admin is fucked-up. This is at first a strength, since you can easily spot extensibility points and as such the learning curve is acceptable, but it quickly becomes a problem. I also think that the main unit of abstraction in Django (the apps) are broken since you care more about resources, even in non-restful projects.
- StavrosK 15y ago
  > it sounds well in practice, until you discover Sphinx. Sphinx does a better job in a more generic way. As someone who started to write our API docs in Sphinx (with an appropriate HTTP extension) but saw this and was about to start using it, your comment may have saved me a few hours of work. Why do you say that Sphinx is better, though? I found that, to document an API, you can either document the code or the API (HTTP-side). Sphinx can do both, but the useful part (HTTP-side documentation) has to be rewritten from scratch and updated separately (unlike the code docs, which can be generated from the docstrings).
  - bad_user 15y ago
    Well, here's a cool plugin I've been using lately: https://github.com/deceze/Sphinx-HTTP-domain https://github.com/deceze/Sphinx-HTTP-domain For documenting code, Sphinx has the advantage that you can use it for cool stuff like testing the sample code provided. See here: http://sphinx.pocoo.org/ext/doctest.html http://sphinx.pocoo.org/ext/doctest.html But you won't get away with just docstrings. Good documentation also includes a high-level overview of the API, history of changes, a glossary of terms, etc... It does have a slight learning curve, but it is very extensible while providing enough out-of-the-box already, and some people have been using it to write entire books.
    - StavrosK 15y ago
      That's exactly what I use too, it's not perfect but it gets you 95% of the way there. I didn't find it too hard to learn, I just picked up the examples and was on my way to writing the docs within a few minutes.
StavrosK 15y ago
To be fair, RESTfulness is only really desirable in an API. I wouldn't want each one of my views to be in a class, because most views are GET-only. Even the ones that use POST aren't usually RESTful if it's something like a form submission, so Django's way is the path of least resistance. For our RESTful API, I use this: http://djangosnippets.org/snippets/1071/ http://djangosnippets.org/snippets/1071/
- po 15y ago
  RESTfulness is only really desirable in an API. I wouldn't want each one of my views to be in a class, because most views are GET-only REST doesn't mean each of your views is in a class and being GET-only doesn't mean something isn't RESTful. I'm not sure I understand your reasoning. Even the ones that use POST aren't usually RESTful if it's something like a form submission It doesn't have to be that way. The path of least resistance is something that the framework determines. In many web-frameworks, the path of least resistance is to do everything (the default web dispatch) in a REST-ful style because that's the way the framework leans.
  - StavrosK 15y ago
    > REST doesn't mean each of your views is in a class and being GET-only doesn't mean something isn't RESTful. So what's unRESTful about Django?
    - po 15y ago
      The framework itself is perfectly capable of supporting REST as the article we are discussing is evidence. My point is that the default routing, the built-in helper functions, and the documentation for beginners all discourage it. For example, the router does not route differently based on the HTTP method. It only takes the URL into account and leaves it to the developer to make a switch based on if the method is GET or POST. This means you're effectively doing some of the routing in the urls.py and some of the routing inside your view. Several of these REST frameworks above (for example the dagny project I mentioned) change that. I think REST is a good enough design pattern that the framework should lean heavily toward it by default. My main site is django so I appreciate the flexibility I get from it. I think it should be possible to do non-REST. This is one thing that I struggled with as a new user. I thought Django would lead me down the right path and in my opinion the default routing is weak.
tomchristie 15y ago
> Roll your own (surprisingly common since it's not too hard) Easy to roll your own. Deceptively hard to do it really simply and really well. Hence the proliferation of frameworks. I like a comment by Fielding here: "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."

by po 15y ago

bad_user 15y ago

There are so many alternatives because most of them suck. I've had the misfortune of choosing Piston for a production app. The API broke several times, not to mention the version I'm using which is fairly recent is still having problems rendering the documentation (triggers a weird error and then server requires a restart). Also, automated documentation is NOT a feature you want, it's just something on which devs waist time - it sounds well in practice, until you discover Sphinx. Sphinx does a better job in a more generic way. I don't get it why people reinvent the wheel. Django's routing is fine IMHO and you can always write your own magic decorators or classes to add on top and it's not that hard to do. Django's problem is that it doesn't provide guidance on what goes where and how. Even the standard project structure that's first created by django-admin is fucked-up. This is at first a strength, since you can easily spot extensibility points and as such the learning curve is acceptable, but it quickly becomes a problem. I also think that the main unit of abstraction in Django (the apps) are broken since you care more about resources, even in non-restful projects.

StavrosK 15y ago
> it sounds well in practice, until you discover Sphinx. Sphinx does a better job in a more generic way. As someone who started to write our API docs in Sphinx (with an appropriate HTTP extension) but saw this and was about to start using it, your comment may have saved me a few hours of work. Why do you say that Sphinx is better, though? I found that, to document an API, you can either document the code or the API (HTTP-side). Sphinx can do both, but the useful part (HTTP-side documentation) has to be rewritten from scratch and updated separately (unlike the code docs, which can be generated from the docstrings).
- bad_user 15y ago
  Well, here's a cool plugin I've been using lately: https://github.com/deceze/Sphinx-HTTP-domain https://github.com/deceze/Sphinx-HTTP-domain For documenting code, Sphinx has the advantage that you can use it for cool stuff like testing the sample code provided. See here: http://sphinx.pocoo.org/ext/doctest.html http://sphinx.pocoo.org/ext/doctest.html But you won't get away with just docstrings. Good documentation also includes a high-level overview of the API, history of changes, a glossary of terms, etc... It does have a slight learning curve, but it is very extensible while providing enough out-of-the-box already, and some people have been using it to write entire books.
  - StavrosK 15y ago
    That's exactly what I use too, it's not perfect but it gets you 95% of the way there. I didn't find it too hard to learn, I just picked up the examples and was on my way to writing the docs within a few minutes.

StavrosK 15y ago

To be fair, RESTfulness is only really desirable in an API. I wouldn't want each one of my views to be in a class, because most views are GET-only. Even the ones that use POST aren't usually RESTful if it's something like a form submission, so Django's way is the path of least resistance. For our RESTful API, I use this: http://djangosnippets.org/snippets/1071/ http://djangosnippets.org/snippets/1071/

po 15y ago
RESTfulness is only really desirable in an API. I wouldn't want each one of my views to be in a class, because most views are GET-only REST doesn't mean each of your views is in a class and being GET-only doesn't mean something isn't RESTful. I'm not sure I understand your reasoning. Even the ones that use POST aren't usually RESTful if it's something like a form submission It doesn't have to be that way. The path of least resistance is something that the framework determines. In many web-frameworks, the path of least resistance is to do everything (the default web dispatch) in a REST-ful style because that's the way the framework leans.
- StavrosK 15y ago
  > REST doesn't mean each of your views is in a class and being GET-only doesn't mean something isn't RESTful. So what's unRESTful about Django?
  - po 15y ago
    The framework itself is perfectly capable of supporting REST as the article we are discussing is evidence. My point is that the default routing, the built-in helper functions, and the documentation for beginners all discourage it. For example, the router does not route differently based on the HTTP method. It only takes the URL into account and leaves it to the developer to make a switch based on if the method is GET or POST. This means you're effectively doing some of the routing in the urls.py and some of the routing inside your view. Several of these REST frameworks above (for example the dagny project I mentioned) change that. I think REST is a good enough design pattern that the framework should lean heavily toward it by default. My main site is django so I appreciate the flexibility I get from it. I think it should be possible to do non-REST. This is one thing that I struggled with as a new user. I thought Django would lead me down the right path and in my opinion the default routing is weak.

tomchristie 15y ago

> Roll your own (surprisingly common since it's not too hard) Easy to roll your own. Deceptively hard to do it really simply and really well. Hence the proliferation of frameworks. I like a comment by Fielding here: "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."