mirror of
https://github.com/encode/django-rest-framework.git
synced 2024-11-22 17:47:04 +03:00
Added PATCH HTTP method to the docs
This commit is contained in:
parent
0f0a07b732
commit
ed13754859
|
@ -134,7 +134,7 @@ If successfully authenticated, `SessionAuthentication` provides the following cr
|
|||
* `request.user` will be a Django `User` instance.
|
||||
* `request.auth` will be `None`.
|
||||
|
||||
If you're using an AJAX style API with SessionAuthentication, you'll need to make sure you include a valid CSRF token for any "unsafe" HTTP method calls, such as `PUT`, `POST` or `DELETE` requests. See the [Django CSRF documentation][csrf-ajax] for more details.
|
||||
If you're using an AJAX style API with SessionAuthentication, you'll need to make sure you include a valid CSRF token for any "unsafe" HTTP method calls, such as `PUT`, `PATCH`, `POST` or `DELETE` requests. See the [Django CSRF documentation][csrf-ajax] for more details.
|
||||
|
||||
# Custom authentication
|
||||
|
||||
|
|
|
@ -83,13 +83,13 @@ You won't typically need to access this property.
|
|||
|
||||
# Browser enhancements
|
||||
|
||||
REST framework supports a few browser enhancements such as browser-based `PUT` and `DELETE` forms.
|
||||
REST framework supports a few browser enhancements such as browser-based `PUT`, `PATCH` and `DELETE` forms.
|
||||
|
||||
## .method
|
||||
|
||||
`request.method` returns the **uppercased** string representation of the request's HTTP method.
|
||||
|
||||
Browser-based `PUT` and `DELETE` forms are transparently supported.
|
||||
Browser-based `PUT`, `PATCH` and `DELETE` forms are transparently supported.
|
||||
|
||||
For more information see the [browser enhancements documentation].
|
||||
|
||||
|
|
|
@ -85,7 +85,7 @@ The following methods are called before dispatching to the handler method.
|
|||
## Dispatch methods
|
||||
|
||||
The following methods are called directly by the view's `.dispatch()` method.
|
||||
These perform any actions that need to occur before or after calling the handler methods such as `.get()`, `.post()`, `put()` and `.delete()`.
|
||||
These perform any actions that need to occur before or after calling the handler methods such as `.get()`, `.post()`, `put()`, `patch()` and `.delete()`.
|
||||
|
||||
### .initial(self, request, \*args, **kwargs)
|
||||
|
||||
|
|
|
@ -5,7 +5,7 @@
|
|||
> — [Alfred North Whitehead][cite], An Introduction to Mathematics (1911)
|
||||
|
||||
|
||||
API may stand for Application *Programming* Interface, but humans have to be able to read the APIs, too; someone has to do the programming. Django REST Framework supports generating human-friendly HTML output for each resource when the `HTML` format is requested. These pages allow for easy browsing of resources, as well as forms for submitting data to the resources using `POST`, `PUT`, and `DELETE`.
|
||||
API may stand for Application *Programming* Interface, but humans have to be able to read the APIs, too; someone has to do the programming. Django REST Framework supports generating human-friendly HTML output for each resource when the `HTML` format is requested. These pages allow for easy browsing of resources, as well as forms for submitting data to the resources using `POST`, `PUT`, `PATCH` and `DELETE`.
|
||||
|
||||
## URLs
|
||||
|
||||
|
@ -79,6 +79,7 @@ The context that's available to the template:
|
|||
* `name` : The name of the resource
|
||||
* `post_form` : A form instance for use by the POST form (if allowed)
|
||||
* `put_form` : A form instance for use by the PUT form (if allowed)
|
||||
* `patch_form` : A form instance for use by the PATCH form (if allowed)
|
||||
* `request` : The request object
|
||||
* `response` : The response object
|
||||
* `version` : The version of Django REST Framework
|
||||
|
|
|
@ -1,12 +1,12 @@
|
|||
# Browser enhancements
|
||||
|
||||
> "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"
|
||||
> "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, PATCH or DELETE"
|
||||
>
|
||||
> — [RESTful Web Services][cite], Leonard Richardson & Sam Ruby.
|
||||
|
||||
## Browser based PUT, DELETE, etc...
|
||||
## Browser based PUT, PATCH, DELETE, etc...
|
||||
|
||||
REST framework supports browser-based `PUT`, `DELETE` and other methods, by
|
||||
REST framework supports browser-based `PUT`, `PATCH`, `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][rails].
|
||||
|
@ -51,7 +51,7 @@ 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)
|
||||
|
||||
## Doesn't HTML5 support PUT and DELETE forms?
|
||||
## Doesn't HTML5 support PUT, PATCH and DELETE forms?
|
||||
|
||||
Nope. It was at one point intended to support `PUT` and `DELETE` forms, but
|
||||
was later [dropped from the spec][html5]. There remains
|
||||
|
|
Loading…
Reference in New Issue
Block a user