Manage your expenses via Email, SMS, iPhone, Twitter, Voice (Call and say your expense), IM (Yahoo, AIM, MSN), or Web.
Django-Piston: REST Framework for Django
Posted
April 30, 2009 
Comments(7)
Comments(7)
Django-Piston in a promising looking REST frameowork for Django. On first inspection it seems to have all the right attributes and setup. I hope to give it a try soon.
[Update] By the way, I’ve been using django-piston in a real project, like it quite a bit. I recommend it.
One question I have – while I agree HTTP PUT and DELETE are the right verbs to use for Update and Delete, in practice they’re not well supported and can cause confusion. I’m wondering if there’s a way to change the mapping to the following:
POST /resource -- Create
POST /resource/id -- Update
POST /resource/id?action=delete -- Delete
GET / resource/id -- Read
Hi,
The GET/POST/PUT/DELETE is at the very core of Piston and there’s no easy way to change this mapping. PUT and DELETE are part of the HTTP specification and are meant exactly for this sort of thing. One of the reasons why this is a Good Thing ™ is that there are very specific rules for what to do when using these, e.g. what to expect.
GET e.g. is “idempotent”, which is just a fancy word for “nothing will change when calling this.” This means you can cache it, and squid/nginx/other proxies will assume this is what’s going on. POST on the other hand, should not update anything, it will always create. DELETE should return 204, and it will also tell caching proxies that a resource is being deleted so it should no longer be cached.
this is a api – all propper clients can do PUT and DELETE
stop fucking up rest with broken things cause of lacks in web browsers
remember POST is not idempotent, but PUT and DELETE are
Thanks for the response Jesper. I’m not looking to argue the Right Way or Good Thing aspects of this issue; as I mentioned I largely agree that PUT and DELETE are good things. In practice, however, there are real issues. Many toolkits and libraries don’t support those verbs very well, so you end up in a situation where a segment of your potential user base simply will not use your api, or you end up with increased customer support issues.
I will let Roy Fielding and Bill de hOra argue it for me though: Roy Fielding: It’s ok to Use POST, Bill de hOra: “Just” Use POST .
Fair enough.
Piston will let you do this, but not I still don’t think you should do it.
A simple way to do it would be to dispatch via your “create” override, and assign that handler to 2 url mappings. Untested code:
urlpatterns = (”,
url(r’^resource$’, someresource),
url(r’resource/(?P\d )$’, someresource),
)
class SomeResource(BaseHandler):
def create(self, request, id_=None):
if not id_:
return super(SomeResource, self).create(request)
else:
if request.GET.get(’action’, ‘void’) == ‘delete’:
self.delete(request, id_) # dispatch to delete
else:
self.update(request, id_) # dispatch to update
It’s not purdy, but it should work.
Thanks Jesper, that makes sense. I have a class that does something similar in my home grown rest framework, hopefully I can replace it with Piston at some point.
Thanks for this discussion (and comments) — I, too, agree, that it’s better overall to support proper UPDATE and DELETE, but I’m having to work with Flex as a client, which only does GET and POST, so this workaround is welcome.
We all should work on hammering the authors of br0ken clients to correct their work asap, not hacking the APIs! Please file a bugreport if flex is not doing it right!