RESTful 仅对一项或多项服务进行增删改查

Question

如果我有一个简单的数据结构，只需要一项服务 (formular) 也可以处理其他表中的相关数据 (formgroups, 字段).

如何区分是更新操作还是在结构中插入新数据的创建操作？（通过诸如 id 之类的东西是否为 null？）
使用一项或多项服务？

数据结构：

{
    "id": 7
    "name": "Formular name",
    "formgroups": [
        {
            "id": 28,
            "formularId": 7
            "name": "General",
            "fields": [
                { "name": "Firstname", "id":107, "formgroupId":28 },
                { "name": "Lastname", "id":108, "formgroupId":28 },
                { "name": "Birthdate", "id":111, "formgroupId":28 }
            ]
        },
        {
            "name": "Address; new group with new fields",
            "fields": [
                { "name": "Street"},
                { "name": "Zip"},
                { "name": "Country"}
            ]
        },
        {
            "name": "Additions",
            "fields": [
                { "name": "First Line"},
                { "name": "Second Line"}
            ]
        }
    ]
}

如果只有一个服务 (/formular)，我会将整个数据结构发送给它，并且需要区分具有 id 的元素，因此它会生成一个更新查询，或者如果它有 none，则使用其相关的“parent”-id 创建记录。

在一项服务中这样做会损害单一责任原则。因为我的公式服务中有来自表单组和字段的逻辑。

我也不确定钩子之前和之后是否与羽毛续集关联一起工作。他们可能被绕过了。

如果使用多个服务（/formular、/formgroup、/field），对 id 进行相同的检查，但客户端应用程序使用 PUT/PATCH 或 POST.

补丁/formular/7

补丁/formgroup/28

补丁/field/108

POST /formgroup（使用公式 ID 7 插入并为下一个字段插入取回表单组 ID 29）

POST /field（插入 'Street'，表单组 ID 为 29）

POST /field（插入 'Zip'，表单组 ID 为 29）

...

但这看起来不对。提出了这么多要求。也许对每个新创建的 formular/formgroup/field 立即这样做是一种解决方案，而不是考虑立即保存整个数据结构。

第三种方式 可能拥有所有服务，但永远不会公开所有服务。将 hole 数据结构发送到 /formular 服务，该服务在内部调用其他服务 /formgroup 和 /field 进行 CRUD 操作。但我不知道这是否仍然适用于 hooks 部分和 feathers-sequelize 功能。

实体关系模型：

我的测试项目的源代码可以在这里找到：https://github.com/Orbitkorbi/feathers-sequelize-test

有关应用程序的其他信息： 我的申请分为两部分。

服务器应用程序运行 feathersjs 并提供 REST API 及其服务。
浏览器中的客户端 SPA 运行调用 API

问题： 如何在 feathersJS 服务、钩子、sequelize 关系和 RESTful API?

方面做到这一点

Answer 1

您使用的是“服务”，而大多数人会根据上下文使用“资源”、“端点”或（更一般地）“模块”。 Answers about "services" 不太可能帮到你。

A third way might be having all the services, but never expose all of them. Sending the hole datastructure to /formular service, where this one calls internally the other services /formgroup and /field for CRUD operations.

这种方法与 REST 最一致。

中心思想是您的“REST API”是一个外观，使您的应用程序看起来像一个通用文档存储（又名网站）。想要向您发送信息的远程客户端通过对您网站上的资源提出编辑建议来实现。

您网站上的每个文档都独立于其他文档，并且可以使用所有文档通用的自我描述消息来建议对该文档的编辑。

因此

PUT /formular

是向服务器建议它使其 /formular 的副本看起来像客户端副本的完全合理的方式。

服务器随后负责 (a) 确定它希望如何更改其资源副本以响应请求，以及 (b) 弄清楚如何进行这些更改。

因此，如果 /formular 是从多个表中的多行构建的资源，服务器将需要自行确定需要哪些数据库语句来适当地更新这些表。

这种复杂性被故意隐藏在 REST facade 的背后 - 就客户端而言，您只是将资源的新表示形式写入某处的文件中。

就单一职责原则而言，请求处理程序只有一个职责——处理请求。您可能希望通过让请求处理程序将部分或全部工作委托给更简单的事情来实现它。

（例如解析HTTP请求，生成HTTP响应等）

RESTful 仅对一项或多项服务进行增删改查

RESTful CRUD to just one or multiple services

rest

feathersjs

feathers-sequelize