Flow Through The Request/Response Cycle

Tastypie can be thought of as a set of class-based view that provide the API functionality. All routing/middleware/response-handling aspectss are the same as a typical Django app. Where the differs is in the view itself.

Walking through what a GET request to a list endpoint looks like:

• The Resource.urls are checked by Django’s url resolvers.

• On a match for the list view, Resource.wrap_view('dispatch_list') is called. wrap_view provides basic error handling & allows for returning serilized errors.

• Because dispatch_list was passed to wrap_view, Resource.dispatch_list is called next. This is a thin wrapper around Resource.dispatch.

• dispatch does a bunch of havy lifting. It ensures:

  • the requested HTTP method is in allowed_methos (method_check).
  • the class has a method that can handle the request(get_list)
  • the user is authenticated(is_authenticated)
  • the user has no exceeded their throttle(throttle_check).

  At this point, dispatch actually calls the requested method (get_list).

• get_list does the actual work of API. It does:

  • A fetch of the available objects via Resource.obj_get_list. In the case of ModelResource, this builds the ORM filters to apply (ModelResource.build_filters). It then gets the QuerySet via ModelResource.get_object_list (which performs Resource.authorized_read_list to possibly limit the set the user can work with) and applies the built filters to it.
  • It then sorts the objects based on user input (ModelResource.apply_sorting).
  • Then it paginates the results using the supplied Paginator & pulls out the data to be serialized.
  • The objects in the page have full_dehydrate applied to each of them, causing Tastypie to traslate the raw object data into the fields the endpoint supports.
  • Finally, it calls Resource.create_response.

• create_response is a shortcut method that:

  • Determines the desired response format (Resource.determine_format).
  • Serializes the data given to it in the proper format.
  • Returns a Django HttpResponse (200 OK) with the serialized data.

• We bubble back up the call stack to dispatch. The last thing dispatch does is potentially store that a request occured for future throttling (Resource.log_throttled_access) then either returns the HttpResponse or wraps whatever data came back in a response (so Django doesn’t freak out).

Resources in Tastypie

Resources are the heart of Tastypie. By defining a resource we can actually convert a model into an API stream. The data is automatically converted into API response.

Understanding the process of creating a resource.

1. Import ModelResource from Tastypie.
2. Import models from services app
3. Create custom resource by inheriting ModelResource and link app model in inner Meta class of resource.

Add API URL in the urls.py of app.

Dehydrating the JSON data

Dehydration in Tastypie means making alterations before sending data to the client. Suppose we need to send capitalized product names instead of small letters. Now we see two kinds of dehydrate methods.

Dehydrate_field method

This dehydrate_field is uesd to modify field on the response JSON.

Dehydrate method

Dehydrate method is useful for aadding additional fields to bundle (response data).

Similarly using hydrate method we can alter the bundle data which is generated from request at the time of PUT or POST methods.