browser enhancements - swinton/django-rest-framework GitHub Wiki
"There are two noncontroversial uses for overloaded POST. The first is to simulate HTTP's uniform interface for clients like web browsers that don't support PUT or DELETE"
— RESTful Web Services, Leonard Richardson & Sam Ruby.
REST framework supports browser-based PUT
, DELETE
and other methods, by
overloading POST
requests using a hidden form field.
Note that this is the same strategy as is used in Ruby on Rails.
For example, given the following form:
<form action="/news-items/5" method="POST">
<input type="hidden" name="_method" value="DELETE">
</form>
request.method
would return "DELETE"
.
REST framework also supports method overriding via the semi-standard X-HTTP-Method-Override
header. This can be useful if you are working with non-form content such as JSON and are working with an older web server and/or hosting provider that doesn't recognise particular HTTP methods such as PATCH
. For example Amazon Web Services ELB.
To use it, make a POST
request, setting the X-HTTP-Method-Override
header.
For example, making a PATCH
request via POST
in jQuery:
$.ajax({
url: '/myresource/',
method: 'POST',
headers: {'X-HTTP-Method-Override': 'PATCH'},
...
});
Browser-based submission of content types other than form are supported by
using form fields named _content
and _content_type
:
For example, given the following form:
<form action="/news-items/5" method="PUT">
<input type="hidden" name="_content_type" value="application/json">
<input name="_content" value="{'count': 1}">
</form>
request.content_type
would return "application/json"
, and
request.stream
would return "{'count': 1}"
REST framework can take ?accept=application/json
style URL parameters,
which allow the Accept
header to be overridden.
This can be useful for testing the API from a web browser, where you don't
have any control over what is sent in the Accept
header.
REST framework can take ?format=json
style URL parameters, which can be a
useful shortcut for determining which content type should be returned from
the view.
This is a more concise than using the accept
override, but it also gives
you less control. (For example you can't specify any media type parameters)
Nope. It was at one point intended to support PUT
and DELETE
forms, but
was later dropped from the spec. There remains
ongoing discussion about adding support for PUT
and DELETE
,
as well as how to support content types other than form-encoded data.