web-services - 你能构建一个 RESTful 业务逻辑层吗？

Question

我为我的架构的数据访问层 (DAL) 构建了一个 RESTful 服务:

POST http://example.com/data/User
GET|PUT|DELETE http://example.com/data/User/{UserId}

但是，对于业务逻辑层 (BLL)，使用了第二个非 RESTful 服务:

POST http://example.com/accountapi/register
POST http://example.com/accountapi/login

此 BLL 服务不调用 DAL 服务，而是直接与数据库对话。

您将如何改进这种架构？

BLL 服务应该调用 DAL 服务吗？

我应该放弃 DAL 服务并只公开 BLL 服务吗？

我是否应该以某种方式在我的 RESTful DAL 服务上注入(inject)业务逻辑 ?如果是，如何？

Answer 1

回答主要问题。不，不是。回答次要问题。以上都不是。

基于 REST 的架构不能很好地适应标准的 3 层模型。三层模型的简化 View 如下所示:

Presentation Layer <-> Business Logic Layer <-> Data Layer

考虑一下将表示层分成两部分，

Rendering Layer <-> User Interface Content <-> BLL <-> DAL

如果您考虑一个常规的 Web 应用程序，浏览器会获取 HTML、CSS 和 Javascript 内容并在浏览器中以可视方式呈现它们。 REST 约束适用于用户界面内容层。如果您考虑超媒体约束，这一点最为明显。 REST 界面意味着可以像用户界面一样进行导航。 REST 接口(interface)返回 re 介绍 s 的资源。

REST 接口(interface)应返回独立于用户界面显示方式的用户界面内容。

REST Client <-> REST Interface <-> BLL <-> DAL

在我看来，REST 客户端有两种形式，一种是非常薄的媒体类型渲染引擎(例如 Web 浏览器)，另一种是屏幕抓取工具(蜘蛛、混搭)。我松散地使用术语“屏幕抓取工具”，因为如果您明智地选择媒体类型，客户端从您的用户界面内容中抓取数据应该是微不足道的。

任何将业务逻辑层公开为 REST 接口(interface)的尝试通常都会产生一些影响。开发人员最终会询问如何在 REST 中进行事务。由于需要公开语义丰富的表示，它们最终在客户端和 BLL 接口(interface)之间创建了大量的耦合。他们忘记了超媒体约束，因为大部分链接信息在业务逻辑层中不可用。他们开始提示 HTTP 和基于文本的内容类型的性能开销。