description，“描述”，类似于pyproject.toml的description字段。

readme，“简介”，类似于pyproject.toml的readme字段。

对某个资源执行bulk_update操作，比如更变两个资源的排序。

API格式如PATCH /<resources>，详见DRF实现。

以及一些DRF内部实现：

• https://levelup.gitconnected.com/really-fast-bulk-updates-with-django-rest-framework-43594b18bd75
• https://stackoverflow.com/questions/47902913/bulk-update-data-in-django-rest-framework

这种方案的好处是比较通用，缺点是没有社区规范和标准支持。

另外一种保守方案是设计一个无状态service，比如reorder方法。

社区没有专门的文档或者最佳实践对排序API的定义，因此我们需要根据我们自己的需求和偏好定义。

PS：Django的order字段解决方案：https://github.com/django-ordered-model/django-ordered-model。

假设资源有所有者，则定义

• 分配allocate：系统（自动或者系统管理员触发）分配所有者
• 申请apply：用户申请自己拥有某个资源，后台根据申请规则决定

方案1：category和tag字段

category是树，tag就是简单打标签分类。这两个加起来也就是简单分类。

方案2：relation表

对于组织、项目等有明确顺序的结构，比较适合使用有向无环图DAG。

对于一般的关联关系，可以使用一般的图结构。

技术实现可以考虑：

1. 图数据库
2. 自研Django框架，实现一般的图和DAG的特性。

生命周期是事物从诞生、成长、成熟到衰退或结束的整个过程。

状态字段被定义为标识生命周期的某个阶段。

状态字段通常是动词的现在进行时或者过去时。

微软云的最佳实践建议：

1. 自定义媒体资源类型，即Content-Type请求头。
2. 在此基础上，在Accept请求头规范资源（xxxx）、版本（如v1）、格式（如JSON）。

详情见：https://learn.microsoft.com/zh-cn/azure/architecture/best-practices/api-design#media-type-versioning

我的进一步想法：

1. 通过本工程规范和其他工程规范定义一系列量潮全局试用的媒体类型，并且允许各个微服务自定义媒体资源类型，比如qtclass-course。
2. 版本号可以支持整数和语义化两种，以适应我们的实际需求。
3. IBM、Red Het的REST规范都可以参考；Google等其他大厂的最佳文档还没有查，都可以广泛学习。

工程实现：

• drf-versioned-schemas库实现的实际上就是这个功能，感觉可以重命名为drf-versioned-mime并增加微软建议的实践。

参考资料：

• MIME: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Basics_of_HTTP/MIME_types

drf-bulk提供了一套直接在REST的方法基础上增加的方案。

project-relations/<id>

分情况讨论：

1. 树。简单的child-parent关系，甚至可以不单独建表。
2. 有向无环图。child-parent的关系稍微复杂，需要单独建表。
3. 无向图。

初步计划

Hierarchy 层级

表示自上而下的金字塔结构的层级，数字越小越高等级。

比如部门层级。

在英语里，Hierarchy是一个不可数名词，指的是有层次的结构，常用Level of Hierarchy，详见见：https://www.tutor2u.net/business/reference/hierarchy

Rank 等级

表示类似于军衔的正式人员等级，数字越大越高等级。

比如员工职级。

职级在英文中最长使用的单词是Rank。由于职级非常类似于军衔，而军衔是Rank，详见：https://dictionary.cambridge.org/dictionary/english/rank

Level 等级

一般的等级，数字越大越高等级。