Chapter 4.  Throttling, Filtering, Testing, and Deploying an API with Django

In this chapter, we will use the additional features included in Django and Django REST Framework to improve our RESTful API. We will also write and execute unit tests and learn a few things related to deployment. We will cover the following topics in this chapter:

  • Understanding throttling classes
  • Configuring throttling policies
  • Testing throttle policies
  • Understanding filtering, searching and ordering classes
  • Configuring filtering, searching, and ordering for views
  • Testing filtering, searching and ordering features
  • Filter, search, and order in the browsable API
  • Writing a first round of unit tests
  • Running unit tests and checking testing coverage
  • Improving testing coverage
  • Understanding strategies for deployments and scalability

Understanding throttling classes

So far, we haven't established any limits on the usage of our API, and therefore, both authenticated and unauthenticated users can compose and send as many requests as they want to. We only took advantage of the pagination features available in Django REST Framework to specify how we wanted large results sets to be split into individual pages of data. However, any user can compose and send thousands of requests to be processed without any kind of limitation.

We will use throttling to configure the following limitations of the usage of our API:

  • Unauthenticated users: A maximum of five requests per hour.
  • Authenticated users: A maximum of 20 requests per hour.

In addition, we want to configure a maximum of 100 requests per hour to the game categories related views, no matter whether the user is authenticated or not.

Django REST Framework provides the following three throttling classes in the rest_framework.throttling module. All of them are subclasses of the SimpleRateThrottle class, which is a subclass of the BaseThrottle class. The classes allow us to set the maximum number of requests per period that are computed based on different mechanisms to determine the previous request information used to specify the scope. The previous request information for throttling is stored in the cache and the classes override the get_cache_key method that determines the scope.

  • AnonRateThrottle: This class limits the rate of request that an anonymous user can make. The IP address of the request is the unique cache key, and therefore, all the requests coming from the same IP address will accumulate the total number of requests.
  • UserRateThrottle: This class limits the rate at which a specific user can make requests. For authenticated users, the authenticated user ID is the unique cache key. For anonymous users, the IP address of the request is the unique cache key.
  • ScopedRateThrottle: This class limits the rate of request for specific parts of the API identified with the value assigned to the throttle_scope property. The class is useful when we want to restrict access to specific parts of the API with different rates.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.14.251.128