django tastypie基本使用

1. Tastypie RESTful API请求处理的基本流程描述

Tastypie 是一个基于Python在Django平台上用来创建RESTFul API 框架, 在创建RESTful API 方面提供了强大的功能, 同时在使用上可以很方便地利用Django 自身的Model作为数据源, 也可以很方便地使用非ORM数据源来提供API数据。

除了提供基本的数据功能之外, Tastypie 还提供了 登录验证, 权限控制, 数据验证, 数据缓存, 请求控制, 数据分页, 数据序列与反序列化等功能选项, 来增加API对数据源的各个方面的控制, 以方便我们在数据访问的不同阶段进行控制。

Tastypie 的主要框架架构组成为Api+Resource, Api是一个包含多个Resource集合的对象, Resource通过注册到Api对象中, 然后通过Api对象来进行统一管理. Resource 是一个资源管理实例, 在其中提供真正的资源数据管理, 上述的相关数据源控制的功能特性都是通过选项配置到Resource中来实现的, 也正是这种方式使得功能特性的实现与具体的Resource可以隔离进行处理, 做到逻辑上的解耦。

Tastypie 处理 RESTFul API 基本流程根据请求方式的不同分为三种: 用户读取数据, 用户生成或更新数据, 用户删除数据。

用户读取数据

• 读取数据列表: get_list

    1. 接收用户发送请求中的 查询参数集合(包括GET和 URLConf 中的kwargs), 通过 build_filters 来构造数据过滤器
    2. 使用 apply_filters 来将这些过滤器应用到原始数据源集合中来过滤符合条件的一部分数据
    3. 接收用户的GET请求中的 排序参数(默认为 order_by) 来对2中过滤后的数据进行排序处理: apply_sorting
    4. 根据用户的GET请求中的 分页参数(每页数据 limit 和 当前位移 offset)来对3中的数据进行分页处理: Paginator 对象专门处理.
    5. 将分页后的数据进行序列化处理:  full_dehydrate()->dehydrate_fieldname->dehydrate()
    6. 对序列化之后的数据做最后修改: alter_list_data_to_serialize

• 读取特定数据对象明细: get_detail

    1. 查询缓存器中的数据对象: cached_obj_get :Cache 配置选项.
    2. 序列化1中返回的数据对象: full_dehydrate->dehydrate_fieldname->dehydrate
    3. 最后修改2中序列化后的数据: alter_detail_data_to_serialize

用户生成或更新数据: post_list / post_detail / put_list / put_detail / patch_list / patch_detail:

• 创建一个新的资源对象: post_list

1. 用户发送数据的反序列化操作(deserialize), 将用户发送的文本数据转换为Python对象
2. 一个额外的用户接口来修改1中生成的数据对象, 这个是用户层级自定义的: alter_deserialized_detail_data
3. 根据最后的反序列化后的数据生成Bundle对象: build_bundle
4. 根据用户发送数据创建一个新的数据对象: obj_create: ** 在 Resource 中没有实现 **
5. 根据 Meta中的 always_return_data 来确定是否返回新建数据对象

• 使用一个资源集合来替换另外的一个资源集合: put_list

1. 反序列化用户的请求数据到python对象
2. 删除用户请求对应的资源来准备后续的更新操作: obj_delete_list_for_update: ** 在 Resource 中没有实现 **
3. 按照用户的请求数据批量地创建新的数据对象: obj_create(此过程是一个事务单元, 出现异常会通过 rollback 来进行事务回滚)
4. 根据 Meta 中的 always_return_data 来确定是否返回新更新的数据集合

• 更新一个已有资源或者创建一个新的资源对象: put_detail

1. 反序列化用户的请求数据: deserialize
2. 用户级别来修改反序列化后的数据对象: alter_deserliazed_detail_data
3. 尝试更新数据: obj_update
4. 更新失败后就创建新数据对象: obj_create
5. 根据 Meta 中的 always_return_data 参数来确定操作成功后是否返回新数据给客户端.

• 直接替换一个资源集合: patch_list

1. 将请求中的post动作转换为 patch动作: convert_post_to_patch
2. 对用户请求数据进行反序列化操作: deserialize
3. 根据反序列化中各个数据对象的 resource_uri 字段值以及 get_via_uri 来查看是否能够逆向得到Resource实例
4. 如果能够逆向获取Resource实例数据对象, 则尝试更新数据: update_in_place(), 否则就新创建一个数据对象: obj_create()
5. 检查请求集合中请求删除的数据集合, 如果当前Resource 允许删除请求, 则调用 obj_delete() 函数来删除请求中要删除的数据集合.

• 直接更新一个资源对象: patch_detail

1. 将用户请求的post动作转换为patch动作: convert_post_to_patch
2. 尝试从缓存中获取资源实例对象
3. 对用户请求数据进行反序列化处理
4. 调用 update_in_place 来直接更新资源对象实例
5. 根据 Meta 中的 always_return_data 来确定是否返回更新后的数据实例对象.

用户删除数据:

• 删除数据列表: delete_list

1.调用 obj_delete_list() 来删除数据列表: * 在 Resource 中没有实现 *
2.返回 HttpNoContent 对象

• 删除具体数据对象:delete_detail

1.调用 obj_delete() 来删除数据对象: * 在 Resource 中没有实现*
2.返回 HttpNoContent 或 HttpNotFound