aboutsummaryrefslogtreecommitdiffstats
path: root/docs/api-guide
diff options
context:
space:
mode:
Diffstat (limited to 'docs/api-guide')
-rw-r--r--docs/api-guide/authentication.md2
-rw-r--r--docs/api-guide/content-negotiation.md8
-rw-r--r--docs/api-guide/exceptions.md4
-rw-r--r--docs/api-guide/fields.md8
-rw-r--r--docs/api-guide/parsers.md4
-rw-r--r--docs/api-guide/permissions.md2
-rw-r--r--docs/api-guide/renderers.md4
-rw-r--r--docs/api-guide/requests.md12
-rw-r--r--docs/api-guide/responses.md2
-rw-r--r--docs/api-guide/reverse.md2
-rw-r--r--docs/api-guide/serializers.md4
-rw-r--r--docs/api-guide/throttling.md6
12 files changed, 29 insertions, 29 deletions
diff --git a/docs/api-guide/authentication.md b/docs/api-guide/authentication.md
index 5e5ee4ed..7bad4867 100644
--- a/docs/api-guide/authentication.md
+++ b/docs/api-guide/authentication.md
@@ -86,7 +86,7 @@ You'll also need to create tokens for your users.
token = Token.objects.create(user=...)
print token.key
-For clients to authenticate, the token key should be included in the `Authorization` HTTP header. The key should be prefixed by the string literal "Token", with whitespace seperating the two strings. For example:
+For clients to authenticate, the token key should be included in the `Authorization` HTTP header. The key should be prefixed by the string literal "Token", with whitespace separating the two strings. For example:
Authorization: Token 9944b09199c62bcf9418ad846dd0e4bbdfc6ee4b
diff --git a/docs/api-guide/content-negotiation.md b/docs/api-guide/content-negotiation.md
index 78dc0747..10288c94 100644
--- a/docs/api-guide/content-negotiation.md
+++ b/docs/api-guide/content-negotiation.md
@@ -12,7 +12,7 @@ Content negotiation is the process of selecting one of multiple possible represe
## Determining the accepted renderer
-REST framework uses a simple style of content negotition to determine which media type should be returned to a client, based on the available renderers, the priorities of each of those renderers, and the client's `Accept:` header. The style used is partly client-driven, and partly server-driven.
+REST framework uses a simple style of content negotiation to determine which media type should be returned to a client, based on the available renderers, the priorities of each of those renderers, and the client's `Accept:` header. The style used is partly client-driven, and partly server-driven.
1. More specific media types are given preference to less specific media types.
2. If multiple media types have the same specificity, then preference is given to based on the ordering of the renderers configured for the given view.
@@ -41,9 +41,9 @@ This is a valid approach as the HTTP spec deliberately underspecifies how a serv
# Custom content negotiation
-It's unlikley that you'll want to provide a custom content negotiation scheme for REST framework, but you can do so if needed. To implement a custom content negotiation scheme override `BaseContentNegotiation`.
+It's unlikely that you'll want to provide a custom content negotiation scheme for REST framework, but you can do so if needed. To implement a custom content negotiation scheme override `BaseContentNegotiation`.
-REST framework's content negotiation classes handle selection of both the approprate parser for the requesr, and the appropriate renderer for the response, so you should implement both the `.select_parser(request, parsers)` and `.select_renderer(request, renderers, format_suffix)` methods.
+REST framework's content negotiation classes handle selection of both the appropriate parser for the request, and the appropriate renderer for the response, so you should implement both the `.select_parser(request, parsers)` and `.select_renderer(request, renderers, format_suffix)` methods.
## Example
@@ -63,4 +63,4 @@ request when selecting the appropriate parser or renderer.
"""
return renderers[0]
-[accept-header]: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html \ No newline at end of file
+[accept-header]: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
diff --git a/docs/api-guide/exceptions.md b/docs/api-guide/exceptions.md
index 33cf1ca8..ba57fde8 100644
--- a/docs/api-guide/exceptions.md
+++ b/docs/api-guide/exceptions.md
@@ -25,7 +25,7 @@ For example, the following request:
DELETE http://api.example.com/foo/bar HTTP/1.1
Accept: application/json
-Might recieve an error response indicating that the `DELETE` method is not allowed on that resource:
+Might receive an error response indicating that the `DELETE` method is not allowed on that resource:
HTTP/1.1 405 Method Not Allowed
Content-Type: application/json; charset=utf-8
@@ -85,4 +85,4 @@ Raised when an incoming request fails the throttling checks.
By default this exception results in a response with the HTTP status code "429 Too Many Requests".
-[cite]: http://www.doughellmann.com/articles/how-tos/python-exception-handling/index.html \ No newline at end of file
+[cite]: http://www.doughellmann.com/articles/how-tos/python-exception-handling/index.html
diff --git a/docs/api-guide/fields.md b/docs/api-guide/fields.md
index dc9ab045..b3cf186c 100644
--- a/docs/api-guide/fields.md
+++ b/docs/api-guide/fields.md
@@ -42,7 +42,7 @@ A serializer definition that looked like this:
class Meta:
fields = ('url', 'owner', 'name', 'expired')
-Would produced output similar to:
+Would produce output similar to:
{
'url': 'http://example.com/api/accounts/3/',
@@ -51,7 +51,7 @@ Would produced output similar to:
'expired': True
}
-Be default, the `Field` class will perform a basic translation of the source value into primative datatypes, falling back to unicode representations of complex datatypes when neccesary.
+By default, the `Field` class will perform a basic translation of the source value into primative datatypes, falling back to unicode representations of complex datatypes when necessary.
You can customize this behaviour by overriding the `.to_native(self, value)` method.
@@ -84,7 +84,7 @@ or `django.db.models.fields.TextField`.
## EmailField
-A text representation, validates the text to be a valid e-mail adress. Corresponds to `django.db.models.fields.EmailField`
+A text representation, validates the text to be a valid e-mail address. Corresponds to `django.db.models.fields.EmailField`
## DateField
@@ -165,7 +165,7 @@ And a model serializer defined like this:
model = Bookmark
exclude = ('id',)
-The an example output format for a Bookmark instance would be:
+Then an example output format for a Bookmark instance would be:
{
'tags': [u'django', u'python'],
diff --git a/docs/api-guide/parsers.md b/docs/api-guide/parsers.md
index c35dfd05..ac904720 100644
--- a/docs/api-guide/parsers.md
+++ b/docs/api-guide/parsers.md
@@ -8,7 +8,7 @@ sending more complex data than simple forms
>
> — Malcom Tredinnick, [Django developers group][cite]
-REST framework includes a number of built in Parser classes, that allow you to accept requests with various media types. There is also support for defining your own custom parsers, which gives you the flexiblity to design the media types that your API accepts.
+REST framework includes a number of built in Parser classes, that allow you to accept requests with various media types. There is also support for defining your own custom parsers, which gives you the flexibility to design the media types that your API accepts.
## How the parser is determined
@@ -65,7 +65,7 @@ Parses `YAML` request content.
Parses REST framework's default style of `XML` request content.
-Note that the `XML` markup language is used typically used as the base language for more strictly defined domain-specific languages, such as `RSS`, `Atom`, and `XHTML`.
+Note that the `XML` markup language is typically used as the base language for more strictly defined domain-specific languages, such as `RSS`, `Atom`, and `XHTML`.
If you are considering using `XML` for your API, you may want to consider implementing a custom renderer and parser for your specific requirements, and using an existing domain-specific media-type, or creating your own custom XML-based media-type.
diff --git a/docs/api-guide/permissions.md b/docs/api-guide/permissions.md
index 249f3938..0b7b32e9 100644
--- a/docs/api-guide/permissions.md
+++ b/docs/api-guide/permissions.md
@@ -6,7 +6,7 @@
>
> — [Apple Developer Documentation][cite]
-Together with [authentication] and [throttling], permissions determine wheter a request should be granted or denied access.
+Together with [authentication] and [throttling], permissions determine whether a request should be granted or denied access.
Permission checks are always run at the very start of the view, before any other code is allowed to proceed. Permission checks will typically use the authentication information in the `request.user` and `request.auth` properties to determine if the incoming request should be permitted.
diff --git a/docs/api-guide/renderers.md b/docs/api-guide/renderers.md
index b3b8d5bc..b6db376c 100644
--- a/docs/api-guide/renderers.md
+++ b/docs/api-guide/renderers.md
@@ -6,7 +6,7 @@
>
> — [Django documentation][cite]
-REST framework includes a number of built in Renderer classes, that allow you to return responses with various media types. There is also support for defining your own custom renderers, which gives you the flexiblity to design your own media types.
+REST framework includes a number of built in Renderer classes, that allow you to return responses with various media types. There is also support for defining your own custom renderers, which gives you the flexibility to design your own media types.
## How the renderer is determined
@@ -229,7 +229,7 @@ For example:
## Designing your media types
-For the purposes of many Web APIs, simple `JSON` responses with hyperlinked relations may be sufficient. If you want to fully embrace RESTful design and [HATEOAS] you'll neeed to consider the design and usage of your media types in more detail.
+For the purposes of many Web APIs, simple `JSON` responses with hyperlinked relations may be sufficient. If you want to fully embrace RESTful design and [HATEOAS] you'll need to consider the design and usage of your media types in more detail.
In [the words of Roy Fielding][quote], "A REST API should spend almost all of its descriptive effort in defining the media type(s) used for representing resources and driving application state, or in defining extended relation names and/or hypertext-enabled mark-up for existing standard media types.".
diff --git a/docs/api-guide/requests.md b/docs/api-guide/requests.md
index 2770c6dd..72932f5d 100644
--- a/docs/api-guide/requests.md
+++ b/docs/api-guide/requests.md
@@ -25,19 +25,19 @@ For more details see the [parsers documentation].
## .FILES
-`request.FILES` returns any uploaded files that may be present in the content of the request body. This is the same as the standard `HttpRequest` behavior, except that the same flexible request parsing that is used for `request.DATA`.
+`request.FILES` returns any uploaded files that may be present in the content of the request body. This is the same as the standard `HttpRequest` behavior, except that the same flexible request parsing is used for `request.DATA`.
For more details see the [parsers documentation].
## .QUERY_PARAMS
-`request.QUERY_PARAMS` is a more correcly named synonym for `request.GET`.
+`request.QUERY_PARAMS` is a more correctly named synonym for `request.GET`.
For clarity inside your code, we recommend using `request.QUERY_PARAMS` instead of the usual `request.GET`, as *any* HTTP method type may include query parameters.
## .parsers
-The `APIView` class or `@api_view` decorator will ensure that this property is automatically to a list of `Parser` instances, based on the `parser_classes` set on the view or based on the `DEFAULT_PARSER_CLASSES` setting.
+The `APIView` class or `@api_view` decorator will ensure that this property is automatically set to a list of `Parser` instances, based on the `parser_classes` set on the view or based on the `DEFAULT_PARSER_CLASSES` setting.
You won't typically need to access this property.
@@ -51,7 +51,7 @@ If a client sends a request with a content-type that cannot be parsed then a `Un
# Authentication
-REST framework provides flexbile, per-request authentication, that gives you the abilty to:
+REST framework provides flexible, per-request authentication, that gives you the ability to:
* Use different authentication policies for different parts of your API.
* Support the use of multiple authentication policies.
@@ -75,7 +75,7 @@ For more details see the [authentication documentation].
## .authenticators
-The `APIView` class or `@api_view` decorator will ensure that this property is automatically to a list of `Authentication` instances, based on the `authentication_classes` set on the view or based on the `DEFAULT_AUTHENTICATORS` setting.
+The `APIView` class or `@api_view` decorator will ensure that this property is automatically set to a list of `Authentication` instances, based on the `authentication_classes` set on the view or based on the `DEFAULT_AUTHENTICATORS` setting.
You won't typically need to access this property.
@@ -83,7 +83,7 @@ You won't typically need to access this property.
# Browser enhancements
-REST framework supports a few browser enhancments such as browser-based `PUT` and `DELETE` forms.
+REST framework supports a few browser enhancements such as browser-based `PUT` and `DELETE` forms.
## .method
diff --git a/docs/api-guide/responses.md b/docs/api-guide/responses.md
index 395decda..794f9377 100644
--- a/docs/api-guide/responses.md
+++ b/docs/api-guide/responses.md
@@ -86,7 +86,7 @@ The `Response` class extends `SimpleTemplateResponse`, and all the usual attribu
**Signature:** `.render()`
-As with any other `TemplateResponse`, this methd is called to render the serialized data of the response into the final response content. When `.render()` is called, the response content will be set to the result of calling the `.render(data, accepted_media_type, renderer_context)` method on the `accepted_renderer` instance.
+As with any other `TemplateResponse`, this method is called to render the serialized data of the response into the final response content. When `.render()` is called, the response content will be set to the result of calling the `.render(data, accepted_media_type, renderer_context)` method on the `accepted_renderer` instance.
You won't typically need to call `.render()` yourself, as it's handled by Django's standard response cycle.
diff --git a/docs/api-guide/reverse.md b/docs/api-guide/reverse.md
index 12346eb4..19930dc3 100644
--- a/docs/api-guide/reverse.md
+++ b/docs/api-guide/reverse.md
@@ -6,7 +6,7 @@
>
> — Roy Fielding, [Architectural Styles and the Design of Network-based Software Architectures][cite]
-As a rule, it's probably better practice to return absolute URIs from you Web APIs, such as `http://example.com/foobar`, rather than returning relative URIs, such as `/foobar`.
+As a rule, it's probably better practice to return absolute URIs from your Web APIs, such as `http://example.com/foobar`, rather than returning relative URIs, such as `/foobar`.
The advantages of doing so are:
diff --git a/docs/api-guide/serializers.md b/docs/api-guide/serializers.md
index 47958fe3..c10a3f44 100644
--- a/docs/api-guide/serializers.md
+++ b/docs/api-guide/serializers.md
@@ -175,7 +175,7 @@ You can add extra fields to a `ModelSerializer` or override the default fields b
class Meta:
model = Account
-Extra fields can corrospond to any property or callable on the model.
+Extra fields can correspond to any property or callable on the model.
## Relational fields
@@ -187,7 +187,7 @@ The `PrimaryKeyRelatedField` and `HyperlinkedRelatedField` fields provide altern
The `ModelSerializer` class can itself be used as a field, in order to serialize relationships using nested representations.
-The `RelatedField` class may be subclassed to create a custom represenation of a relationship. The subclass should override `.to_native()`, and optionally `.from_native()` if deserialization is supported.
+The `RelatedField` class may be subclassed to create a custom representation of a relationship. The subclass should override `.to_native()`, and optionally `.from_native()` if deserialization is supported.
All the relational fields may be used for any relationship or reverse relationship on a model.
diff --git a/docs/api-guide/throttling.md b/docs/api-guide/throttling.md
index 435b20ce..d54433b1 100644
--- a/docs/api-guide/throttling.md
+++ b/docs/api-guide/throttling.md
@@ -80,7 +80,7 @@ The allowed request rate is determined from one of the following (in order of pr
## UserRateThrottle
-The `UserThrottle` will throttle users to a given rate of requests across the API. The user id is used to generate a unique key to throttle against. Unauthenticted requests will fall back to using the IP address of the incoming request to generate a unique key to throttle against.
+The `UserThrottle` will throttle users to a given rate of requests across the API. The user id is used to generate a unique key to throttle against. Unauthenticated requests will fall back to using the IP address of the incoming request to generate a unique key to throttle against.
The allowed request rate is determined from one of the following (in order of preference).
@@ -114,7 +114,7 @@ For example, multiple user throttle rates could be implemented by using the foll
## ScopedRateThrottle
-The `ScopedThrottle` class can be used to restrict access to specific parts of the API. This throttle will only be applied if the view that is being accessed includes a `.throttle_scope` property. The unique throttle key will then be formed by concatenating the "scope" of the request with the unqiue user id or IP address.
+The `ScopedThrottle` class can be used to restrict access to specific parts of the API. This throttle will only be applied if the view that is being accessed includes a `.throttle_scope` property. The unique throttle key will then be formed by concatenating the "scope" of the request with the unique user id or IP address.
The allowed request rate is determined by the `DEFAULT_THROTTLE_RATES` setting using a key from the request "scope".
@@ -152,6 +152,6 @@ User requests to either `ContactListView` or `ContactDetailView` would be restri
To create a custom throttle, override `BaseThrottle` and implement `.allow_request(request, view)`. The method should return `True` if the request should be allowed, and `False` otherwise.
-Optionally you may also override the `.wait()` method. If implemented, `.wait()` should return a recomended number of seconds to wait before attempting the next request, or `None`. The `.wait()` method will only be called if `.allow_request()` has previously returned `False`.
+Optionally you may also override the `.wait()` method. If implemented, `.wait()` should return a recommended number of seconds to wait before attempting the next request, or `None`. The `.wait()` method will only be called if `.allow_request()` has previously returned `False`.
[permissions]: permissions.md