Hi Krzysztof On Mon, May 20, 2013 at 7:48 PM, Krzysztof Jurewicz < [email protected]> wrote:
> There is a RFC describing HTTP method named PATCH: > > http://tools.ietf.org/html/**rfc5789 <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/**293f7a21147ad94c92c7d5b3f33cba > **b2f87b001b<https://github.com/django/django/commit/293f7a21147ad94c92c7d5b3f33cbab2f87b001b> > > In View class: > https://github.com/django/**django/blob/**a93672622829e0d4a2ff3240456d4d** > 73b9d46476/django/views/**generic/base.py#L33<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/**a93672622829e0d4a2ff3240456d4d** > 73b9d46476/django/views/**generic/base.py#L207<https://github.com/django/django/blob/a93672622829e0d4a2ff3240456d4d73b9d46476/django/views/generic/base.py#L207> > > In ProcessFormView: > https://github.com/django/**django/blob/**a93672622829e0d4a2ff3240456d4d** > 73b9d46476/django/views/**generic/edit.py#L164<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/<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/**a93672622829e0d4a2ff3240456d4d** > 73b9d46476/django/views/**generic/edit.py#L44<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<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? > These are all reasonable and fairly small I'd be happy to see these added after the alpha - a ticket and patch would definitely be welcome. The only one that is even remotely controversial to me is the handling of PATCH in ProcessFormView. I agree that there are potential problems with using PUT as an analog of POST, but it largely works in this situation; so I don't know if it's worth deprecating the PUT->POST fallback in this case. Strictly, I think it's actually a separate issue -- the first three points you raise are about allowing PATCH at all; the last point is about how we should deal with PATCH in a specific case. Once the first two items on your list are addressed, it would be possible to implement a patch() method on your own generic view subclass; the question is what Django should be doing as a project to make that implementation easier/more useful. Yours, Russ Magee %-) -- 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.
