The APIView class defines default settings for each view that we can override by specifying the desired values in the settings module, that is, the restful01/settings.py file. It is also possible to override the class attributes in subclasses. In this case, we won't make changes in the settings module, but we have to understand which are the default settings that the APIView class uses. We added the  @api_view decorator, and it automatically makes the APIView use these settings.

The value for the DEFAULT_PARSER_CLASSES setting key specifies a tuple of string whose values indicate the default classes that we want to use for parsing backends. The following lines show the default values:

( 
    'rest_framework.parsers.JSONParser', 
    'rest_framework.parsers.FormParser', 
    'rest_framework.parsers.MultiPartParser' 
) 

When we use the @api_view decorator, the RESTful Web Service will be able to handle any of the following content types through the appropriate parsers. Thus, we will be able to work with the request.data attribute to retrieve the keys and values for each of these content types:

• application/json: Parsed by the rest_framework.parsers.JSONParser class
• application/x-www-form-urlencoded: Parsed by the rest_framework.parsers.FormParser class
• multipart/form-data: Parsed by the rest_framework.parsers.MultiPartParser class

When we access the request.data attribute in the functions, the Django REST framework examines the value for the Content-Type header in the incoming request and determines the appropriate parser to parse the request content. If we use the previously explained default values, the Django REST Framework will be able to parse all of the previously listed content types. Notice that the request must specify the appropriate value for the Content-Type key in the request header.

The value for the DEFAULT_RENDERER_CLASSES setting key specifies a tuple of string whose values indicate the default classes that we want to use for rendering backends. The following lines show the default values:

( 
    'rest_framework.renderers.JSONRenderer', 
    'rest_framework.renderers.BrowsableAPIRenderer', 
) 

When we use the @api_view decorator, the RESTful Web Service will be able to render any of the following content types through the appropriate renderers. We made the necessary changes to work with a rest_framework.response.Response instance to be able to work with these content types:

• application/json: Rendered by the rest_framework.response.JSONRenderer class
• text/html: Rendered by the rest_framework.response.BrowsableAPIRenderer class

So far, we understand the default settings for parsers and renderers. There is an additional part of this puzzle that must select the appropriate renderer for the response based on the requirements specified in the incoming request.

By default, the value for the DEFAULT_CONTENT_NEGOTIATION_CLASS is the rest_framework.negotiation.DefaultContentNegotiation class. When we use the decorator, the web service will use this content negotiation class to select the appropriate renderer for the response, based on the incoming request. This way, when a request specifies that it will accept text/html, the content negotiation class selects the rest_framework.renderers.BrowsableAPIRenderer to render the response and generate text/html instead of application/json.

In the old version of the code, we used the JSONResponse and HttpResponse classes in the functions. The new version replaced the usages of both classes with the rest_framework.response.Response class. This way, the code takes advantage of the content negotiation features. The Response class renders the provided data into the appropriate content type and returns it to the client that made the request.