Now, we will take advantage of all the changes we've made in the code and we will compose and send HTTP requests to make our RESTful Web Service work with different content types. Make sure you've saved all the changes. In case you stopped Django's development server, you will have to start it again as we learned in Chapter 3, Creating API Views, in the section Launching Django's development server, to start running the Django development server.

We want to know which HTTP verbs the toys, collection supports, that is, we want to take advantage of the OPTIONS verb. Run the following command. This time, the command won't produce errors. Remember that the virtual environment we have created in the previous chapters must be activated in order to run the next http command:

    http OPTIONS :8000/toys/

The following is the equivalent curl command:

    curl -iX OPTIONS localhost:8000/toys/

The previous command will compose and send the following HTTP request: OPTIONS http://localhost:8000/toys/. The request will end up running the views.toy_list function, that is, the toy_list function declared within the toys/views.py file. We added the @api_view decorator to this function, and therefore, the function is capable of determining the supported HTTP verbs, the enabled parsing and rendering options. The following lines show the output:

    HTTP/1.0 200 OK
    Allow: POST, OPTIONS, GET
    Content-Length: 167
    Content-Type: application/json
    Date: Mon, 16 Oct 2017 04:28:32 GMT
    Server: WSGIServer/0.2 CPython/3.6.2
    Vary: Accept, Cookie
    X-Frame-Options: SAMEORIGIN
    
    {
        "description": "", 
        "name": "Toy List", 
        "parses": [
            "application/json", 
            "application/x-www-form-urlencoded", 
            "multipart/form-data"
        ], 
        "renders": [
            "application/json", 
            "text/html"
        ]
    }
 

The response header includes an Allow key with a comma-separated list of HTTP verbs supported by the resource collection as its value: POST, OPTIONS, GET. Our request didn't specify the allowed content type, and therefore, the function rendered the response with the default application/json content type.

The response body specifies the Content-type that the resource collection is capable of parsing in the values for the "parses" key and the Content-type that the resource collection is capable of rendering in the values for the "renders" key.

Run the following command to compose and send an HTTP request with the OPTIONS verb for a toy resource. Don't forget to replace 2 with a primary key value of an existing toy in your configuration:

    http OPTIONS :8000/toys/2

The following is the equivalent curl command:

    curl -iX OPTIONS localhost:8000/toys/2

The previous command will compose and send the following HTTP request: OPTIONS http://localhost:8000/toys/2. The request will end up running the views.toy_detail function, that is, the toy_detail function declared within the toys/views.py file. We also added the @api_view decorator to this function, and therefore, it is capable of determining the supported HTTP verbs, the enabled parsing and rendering options. The following lines show a sample output:

    HTTP/1.0 200 OK
    Allow: DELETE, PUT, OPTIONS, GET
    Content-Length: 169
    Content-Type: application/json
    Date: Mon, 16 Oct 2017 04:30:04 GMT
    Server: WSGIServer/0.2 CPython/3.6.2
    Vary: Accept, Cookie
    X-Frame-Options: SAMEORIGIN
    
    {
        "description": "", 
        "name": "Toy Detail", 
        "parses": [
            "application/json", 
            "application/x-www-form-urlencoded", 
            "multipart/form-data"
        ], 
        "renders": [
            "application/json", 
            "text/html"
        ]
    }
  

The response header includes an Allow key with a comma-separated list of HTTP verbs supported by the resource as its value: DELETE, PUT, OPTIONS, GET. The response body specifies the Content-type that the resource is capable of parsing in the values for the "parses" key and the Content-type that the resource collection is capable of rendering in the values for the "renders" key. The resource and the resource collection can parse and render the same content types because everything is handled by the decorator and the APIView class.