There is a RFC describing HTTP method named PATCH:
http://tools.ietf.org/html/rfc5789
Quoting that RFC:
“ The difference between the PUT and PATCH requests is reflected in the
way the server processes the enclosed entity to modify the resource
identified by the Request-URI. In a PUT request, the enclosed entity
is considered to be a modified version of the resource stored on the
origin server, and the client is requesting that the stored version
be replaced. With PATCH, however, the enclosed entity contains a set
of instructions describing how a resource currently residing on the
origin server should be modified to produce a new version.”
Django currently has (seemingly shallow) support for PUT method. Based
on that, I’ve grepped for places in code where it is implemented to see
if support for PATCH could be easily added on a basis of symmetry. Those
places are:
In test client:
There is a `put` method, but `patch` is also implemented:
https://github.com/django/django/commit/293f7a21147ad94c92c7d5b3f33cbab2f87b001b
In View class:
https://github.com/django/django/blob/a93672622829e0d4a2ff3240456d4d73b9d46476/django/views/generic/base.py#L33
`put` is listed in http_method_names
In RedirectView:
`put` is a fallback to .get():
https://github.com/django/django/blob/a93672622829e0d4a2ff3240456d4d73b9d46476/django/views/generic/base.py#L207
In ProcessFormView:
https://github.com/django/django/blob/a93672622829e0d4a2ff3240456d4d73b9d46476/django/views/generic/edit.py#L164
PUT is implemented as a fallback to POST and it seems to assume that
request data is form encoded. While it is not generally true for PUT
method, it looks like a reasonable assumption when processing a form.
However since PATCH request doesn’t have to contain full form data, I
think the best approach may be to not implement `patch` method here
(unless we want to deal with editing only some of the form’s fields –
for example this is the case in Rails, where PATCH will be the primary
method for updates in 4.0 version:
http://weblog.rubyonrails.org/2012/2/25/edge-rails-patch-is-the-new-primary-http-method-for-updates/
). The same stays true to `get_form_kwargs` method in FormMixin:
https://github.com/django/django/blob/a93672622829e0d4a2ff3240456d4d73b9d46476/django/views/generic/edit.py#L44
In general, Django’s approach to whether PUT should be treated as a
request containing form data seems to be inconsistent because we
generate forms in the views, but we refuse to generate PUT QueryDict on
a request object:
https://groups.google.com/d/msg/django-developers/dxI4qVzrBY4/m_9IiNk_p7UJ
. So maybe it’s worth to consider removing PUT support in form
processing just on the basis of consistency.
In conclusion, it seems pretty easy to add basic PATCH support similar
to PUT. So if it gets enough +1s, I’m willing to make a patch and hope
it gets included in 1.6 alpha. Or maybe it is (from a technical point of
view) so small a feature that it doesn‘t need to be merged before alpha
release?
--
Krzysiek
--
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
