3 ms·

Comparisons to django-piston and motivation for creating this library would be helpful.

by tworats 16y ago

zacharyvoase 16y ago
FYI: I’m working on a pretty full suite of documentation at the moment, since the README has become a bit overloaded. The motivation for creating this library was pretty simple: I really like the Rails way of modeling the application around resources, and then ’mounting’ those resources at URLs with the absolute minimum necessary amount of code. This resource-oriented approach is key in building truly ‘RESTful’ web services. I wanted a simple but powerful content negotiation mechanism, which effectively gave me a comprehensive ‘API’ with zero additional effort. I think I’ve achieved that here; for example, adding JSON output support to a specific action is usually a 3-line affair, or you could very easily write a generic renderer and enable it for all actions across your entire site. Finally, even though the Rails inspiration was so strong, I needed to keep Dagny as consistent as possible with the practices and idioms of the Python and Django communities. Again, I think I’ve done pretty well in that regard. In response to your other question, I think Piston is a great library—however, I think the idea that you have to define an API separately from the rest of your site is just the wrong way to do things. I’m also not a big fan of Piston’s architecture and resulting API; it’s not as polished as I’d like it to be (although that’s more of a cosmetic issue).
- numix 16y ago
  Did you check out Tastypie (http://toastdriven.github.com/django-tastypie/ http://toastdriven.github.com/django-tastypie/)? It is also RESTful, and explores some similar ideas as a replacement for Piston, but approaches it in a manner similar to Django models.
  - zacharyvoase 16y ago
    It’s quite a nice solution actually, but I’m afraid it’s far too coupled with the Django models for many of my use cases. A lot of the time you’ll create a Resource without any model to back it—for example, most Rails projects use a UserSession resource for logging in/out, with logging in => new/create, and logging out => edit/destroy.
- tworats 16y ago
  I've gone back and forth on this but generally come back to liking piston's approach - it's worked out to be smarter than everything I've hacked up myself. I have yet to try the unified approach where the html and api views are the same underlying code, but I can see where it has appeal. I could also see where it would get hairy. Will have to try it. I didn't see anything about authentication. Thoughts on OAuth, basic auth? I'd love a nice API enabler for simpler non-django frameworks such as flask as well...

Comparisons to django-piston and motivation for creating this library would be helpful.

by tworats 16y ago

Comparisons to django-piston and motivation for creating this library would be helpful.

FYI: I’m working on a pretty full suite of documentation at the moment, since the README has become a bit overloaded. The motivation for creating this library was pretty simple: I really like the Rails way of modeling the application around resources, and then ’mounting’ those resources at URLs with the absolute minimum necessary amount of code. This resource-oriented approach is key in building truly ‘RESTful’ web services. I wanted a simple but powerful content negotiation mechanism, which effectively gave me a comprehensive ‘API’ with zero additional effort. I think I’ve achieved that here; for example, adding JSON output support to a specific action is usually a 3-line affair, or you could very easily write a generic renderer and enable it for all actions across your entire site. Finally, even though the Rails inspiration was so strong, I needed to keep Dagny as consistent as possible with the practices and idioms of the Python and Django communities. Again, I think I’ve done pretty well in that regard. In response to your other question, I think Piston is a great library—however, I think the idea that you have to define an API separately from the rest of your site is just the wrong way to do things. I’m also not a big fan of Piston’s architecture and resulting API; it’s not as polished as I’d like it to be (although that’s more of a cosmetic issue).

numix 16y ago
Did you check out Tastypie (http://toastdriven.github.com/django-tastypie/ http://toastdriven.github.com/django-tastypie/)? It is also RESTful, and explores some similar ideas as a replacement for Piston, but approaches it in a manner similar to Django models.
- zacharyvoase 16y ago
  It’s quite a nice solution actually, but I’m afraid it’s far too coupled with the Django models for many of my use cases. A lot of the time you’ll create a Resource without any model to back it—for example, most Rails projects use a UserSession resource for logging in/out, with logging in => new/create, and logging out => edit/destroy.
tworats 16y ago
I've gone back and forth on this but generally come back to liking piston's approach - it's worked out to be smarter than everything I've hacked up myself. I have yet to try the unified approach where the html and api views are the same underlying code, but I can see where it has appeal. I could also see where it would get hairy. Will have to try it. I didn't see anything about authentication. Thoughts on OAuth, basic auth? I'd love a nice API enabler for simpler non-django frameworks such as flask as well...