Sometimes, we don't know which are the HTTP methods or verbs that a resource or resource collection supports in a RESTful Web Service. In order to provide a solution to this problem, we can compose and send an HTTP request with the OPTIONS HTTP verb and the URL for the resource or the resource collection.

If the RESTful Web Service implements the OPTIONS HTTP verb for a resource or resource collection, it will build a response with an Allow key in the response header. The value for this key will include a comma-separated list of HTTP verbs or methods that it supports. In addition, the response header will include additional information about other supported options, such as the content type it is capable of parsing from the request and the content type it is capable of rendering in the response.

For example, if we want to know which HTTP verbs the toys collection supports, we can run the following command:

    http OPTIONS :8000/toys/

Notice that the command will generate an error in the Django development server.

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 specifies /toys/, and therefore, it will match the '^toys/$' regular expression and run the views.toy_list function, that is, the toy_list function declared within the toys/views.py file. This function only runs code when the request.method is equal to either 'GET' or 'POST'. In this case, request.method is equal to 'OPTIONS', and therefore, the function won't run any code. The function won't return the expected HttpResponse instance.

The lack of the expected HttpResponse instance generates an internal server error in Django's development server. The console output for the development server will display details about the internal server error and a traceback similar to the one shown in the next screenshot. The last lines indicate that there is a ValueError because the toys_list function didn't return an HttpResponse instance and returned None instead:

The following lines show the header for the output displayed as a result of the HTTP request. The response also includes a detailed HTML document with a huge amount of information about the error because the debug mode is activated for Django. We receive an HTTP 500 Internal Server Error status code. Obviously, we don't want all this information to be provided in a production-ready web service, in which we will deactivate the debug mode:

    HTTP/1.0 500 Internal Server Error
    Content-Length: 52222
    Content-Type: text/html
    Date: Tue, 10 Oct 2017 17:46:34 GMT
    Server: WSGIServer/0.2 CPython/3.6.2
    Vary: Cookie
    X-Frame-Options: SAMEORIGIN

We don't want our web service to provide a response with an HTTP 500 Internal Server Error status code when we receive a request with the OPTIONS verb to either a valid resource or resource collection. Obviously, we want to provide a more consistent web service and we want to provide an accurate response when we receive a request with the OPTIONS verbs, for either a toy resource or the toys collection.

If we compose and send an HTTP request with the OPTIONS verb for an existing toy resource, we will see the same error in the console output for the development server and a similar response with the HTTP 500 Internal Server Error status code. The views.toy_detail function only runs code when the request.method is equal to 'GET', 'PUT', or 'DELETE'. Thus, as happened with the previous case, the toys_detail function won't return an HttpResponse instance and it will return None instead.

The following commands will produce the explained error when we try to see the options offered for the toy resource whose id or primary key is equal to 2. Make sure you 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 following screenshot shows the details of the internal server error and a traceback displayed in the console output for the development server after we run the previous HTTP request: