@@ -195,9 +195,9 @@ For more details on using filter sets see the [django-filter documentation][djan
...
@@ -195,9 +195,9 @@ For more details on using filter sets see the [django-filter documentation][djan
## SearchFilter
## SearchFilter
The `SearchFilterBackend` class supports simple single query parameter based searching, and is based on the [Django admin's search functionality][search-django-admin].
The `SearchFilter` class supports simple single query parameter based searching, and is based on the [Django admin's search functionality][search-django-admin].
The `SearchFilterBackend` class will only be applied if the view has a `search_fields` attribute set. The `search_fields` attribute should be a list of names of text type fields on the model, such as `CharField` or `TextField`.
The `SearchFilter` class will only be applied if the view has a `search_fields` attribute set. The `search_fields` attribute should be a list of names of text type fields on the model, such as `CharField` or `TextField`.
If your building a javascript client to interface with your Web API, you'll need to consider if the client can use the same authentication policy that is used by the rest of the website, and also determine if you need to use CSRF tokens or CORS headers.
If you’re building a JavaScript client to interface with your Web API, you'll need to consider if the client can use the same authentication policy that is used by the rest of the website, and also determine if you need to use CSRF tokens or CORS headers.
AJAX requests that are made within the same context as the API they are interacting with will typically use `SessionAuthentication`. This ensures that once a user has logged in, any AJAX requests made can be authenticated using the same session-based authentication that is used for the rest of the website.
AJAX requests that are made within the same context as the API they are interacting with will typically use `SessionAuthentication`. This ensures that once a user has logged in, any AJAX requests made can be authenticated using the same session-based authentication that is used for the rest of the website.
@@ -115,6 +115,7 @@ The context that's available to the template:
...
@@ -115,6 +115,7 @@ The context that's available to the template:
*`name` : The name of the resource
*`name` : The name of the resource
*`post_form` : A form instance for use by the POST form (if allowed)
*`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)
*`put_form` : A form instance for use by the PUT form (if allowed)
*`display_edit_forms` : A boolean indicating whether or not POST, PUT and PATCH forms will be displayed
*`request` : The request object
*`request` : The request object
*`response` : The response object
*`response` : The response object
*`version` : The version of Django REST Framework
*`version` : The version of Django REST Framework
...
@@ -122,6 +123,8 @@ The context that's available to the template:
...
@@ -122,6 +123,8 @@ The context that's available to the template:
*`FORMAT_PARAM` : The view can accept a format override
*`FORMAT_PARAM` : The view can accept a format override
*`METHOD_PARAM` : The view can accept a method override
*`METHOD_PARAM` : The view can accept a method override
You can override the `BrowsableAPIRenderer.get_context()` method to customise the context that gets passed to the template.
#### Not using base.html
#### Not using base.html
For more advanced customization, such as not having a Bootstrap basis or tighter integration with the rest of your site, you can simply choose not to have `api.html` extend `base.html`. Then the page content and capabilities are entirely up to you.
For more advanced customization, such as not having a Bootstrap basis or tighter integration with the rest of your site, you can simply choose not to have `api.html` extend `base.html`. Then the page content and capabilities are entirely up to you.
@@ -85,7 +85,7 @@ Right, we'd better write some views then. Open `quickstart/views.py` and get ty
...
@@ -85,7 +85,7 @@ Right, we'd better write some views then. Open `quickstart/views.py` and get ty
queryset = Group.objects.all()
queryset = Group.objects.all()
serializer_class = GroupSerializer
serializer_class = GroupSerializer
Rather that write multiple views we're grouping together all the common behavior into classes called `ViewSets`.
Rather than write multiple views we're grouping together all the common behavior into classes called `ViewSets`.
We can easily break these down into individual views if we need to, but using viewsets keeps the view logic nicely organized as well as being very concise.
We can easily break these down into individual views if we need to, but using viewsets keeps the view logic nicely organized as well as being very concise.