Browseable API doesn't show the fancy html form for PATCH requests

[ionelmc]

PATCH requests show only the the raw form in the browseable api (that one with just the content type and the text field). In contrast PUT requests get the form with all the fields from the serializer.

I would like to understand why there's only handling for PUT/POST, eg:

django-rest-framework/rest_framework/renderers.py

Lines 689 to 696 in 22d206c

	'response_headers': response_headers,
	'put_form': self.get_rendered_html_form(data, view, 'PUT', request),
	'post_form': self.get_rendered_html_form(data, view, 'POST', request),
	'delete_form': self.get_rendered_html_form(data, view, 'DELETE', request),
	'options_form': self.get_rendered_html_form(data, view, 'OPTIONS', request),
	'extra_actions': self.get_extra_actions(view, response.status_code),

Is this just an oversight or there's something more complicated that prevents just adding a 'patch_form': self.get_rendered_html_form(data, view, 'PATCH', request), in there?

[baseplate-admin]

I actually also want to know the reasoning behind this decision.

Should we raise an issue to get more attention ?

_{Or maybe a Pull Request addressing this would be more efficient}

[auvipy]

I don't know the exact reason behind this, but if this is nothing super complicated and don't break any existing working functionality & don't add any new public API surface, then I think we could consider a patch to improve usability in this area.

[baseplate-admin]

_{Thanks, Its really nice to see DRF being actually maintained. I was really frustrated to see DRF not being maintained for a long time.}

_{also i am personally a big fan of you}

So should we raise a issue from this discussion or a Pull Request?

[auvipy]

A pull request would be great & reduce redundant process

[baseplate-admin]

In which case i will wait for @ionelmc, input before taking a shot at this myself :)

[ionelmc]

Feel free to take a shot, I am swamped :-)