As a general rule, each group of endpoints is seen as a resource. When I say a group of endpoints I mean a collection of HTTP methods on a specific route (e.g. GET, POST and DELETE on /api/entity).

These resources have a lot of features, which include allowing you to access the endpoint with specific HTTP methods, permitting access only if you are authenticated, paginating the results etc.

In Tastypie, there are 3 types of endpoints:

1. list
2. detail
3. custom

List endpoints return a list of objects (as the name implies) and it looks like `host_address/api/entity`. 

Detail endpoints return a single instance of an object and it looks similar to the list endpoint, except for the fact that it expects a path param, the ID of the object, to identify the instance that will be returned (e.g. `/api/entity/[id]`).

Custom endpoints are routes made by developers to solve any use-cases different from the default ones. They don't have a specific format, offering devs more freedom.

Each endpoint needs a function to manipulate and return the data. But these functions have a standard format

• They have as parameters `self` (being a class method inside the resource), `request` (which is the `Request` instance of the client's API call
• They expect the returned value to be a HttpResponse. For best-practice and convenience, there is a method called `create_response` that takes care of that. All you need to pass is the request and the object that you want to be included

Now let's focus on what's the steps for a request to be fulfilled on a Tastypie endpoint.

When a request is received from a client, Django checks for any existing routes inside `urlpatterns`, the variable with all the available routes inside the project.

If a pattern was found, Django will call the associated view (function or class) with the following parameters:

1. an instance of HttpRequest
2. extra params got from the URL

If the URL didn't match any pattern, then Django will take care of it via an appropriate error handling view.

Once Django redirects the request to a Tastypie resource, it checks for the available URLs and lets Tastypie do the rest.  

Assuming the URL is`host-domain/api/v1/entity/` (which is a list view):

If the view was matched, `Resource.wrap_view('dispatch_list')` is called. The wrap_view method inside the Resource takes care of basic error handling and serialisation for the errors. The 'dispatch_list' parameter means that Resource.dispatch_list will be called next (a thin wrapper around the dispatch method).

The dispatch method makes sure the followings are fulfilled:

• the HTTP Method inside the request is allowed in the resource
• the resource has a method that can handle the request (e.g. get_list, get_detail, get_custom_endpoint)
• the user is authenticated
• the user did not exceed their throttle

The response is generated using the specific class method of the resource. If it's a default endpoint, the methods look like [HTTP_method]_[view_type] (e.g. get_list, post_detail) and if it's a custom endpoint, the method's name is the defined route for the endpoint (e.g. add_more_entries)

The following actions will be done when calling the get_list:

1. All the available objects are fetched via `Resource.obj_get_list`
2. Objects are sorted via `Resource.apply_sorting` and paginated with the built-in Paginator
3. the data will be dehydrated, meaning Tastypie will keep only the allowed fields
4. `Resource.create_response` is called, which serializes the data in the proper format and returns a HttpResponse object with the data

Observation: For POST/PUT, there will be an extra step, the hydrate cycle, that will take the request payload and convert it in raw data, for DB storage

Once the Tastypie returned the HttpResponse object, Django will send it to the client which made the request.

As a conclusion, you can consider Tastypie endpoints some Django views which return processed data in standardized formats (or HTTP errors, based on the case).