REST API 中的分层系统约束答案

【问题标题】：Layered system constraint in REST APIREST API 中的分层系统约束
【发布时间】：2015-07-29 22:51:39
【问题描述】：

我正在尝试更多地了解 REST，并尝试了解分层系统在 REST 架构中的含义。据我了解，这意味着如果 API 有数据库，它应该在不同服务器上的不同机器上，并且 api 在需要时调用它。与业务逻辑相同，如果调用应该通过某个逻辑调用被转移到其他一些服务器并在那里执行。如果存在，这也将有助于解决性能问题。我对吗？请提供任何其他信息

【问题讨论】：

标签： web-services rest web server layered

【解决方案1】：

好吧，我不会将分层系统视为“每一层都必须驻留在单独的服务器中”。它更多的是关注点分离，即每一层都应该有一个单一的高级目的并且只处理接着就，随即。我会尝试用一个错误的例子来更好地解释：

@GET
public String myService() {
    return "<html><body><div>HELLO</div></body></html>";
}

在这里，您将服务层和表示层混合在一起。反而，服务应该只返回“HELLO”，而客户端（我假设这里是一个表示层）应该能够决定如何呈现数据。最常见的架构之一是所谓的 3 层架构，其中你有数据访问、业务逻辑和演示。服务可以作为单独的层添加，最常见的是在业务逻辑和表示之间（这样您就可以将相同的业务逻辑应用于不同的客户端，例如 Web 和移动）。

【讨论】：

所以我从你的例子中了解到，分层系统应该是这样的：@GET public String myService(String mimeTipe) { return someClass.someMethod(mimeTipe); } 所以会调用方法并给他参数，我们的方法中没有硬编码页面，对吧？
是的，完全正确。然后服务的客户端可以决定什么是呈现数据的最佳方式，这是服务几乎不知道的事情（例如，客户端是在桌面/移动浏览器中运行的 javascript）。