Architecture web应用程序中真正的客户机-服务器体系结构的陷阱？

我一直在研究如何以真正的客户机-服务器方式构建web应用程序

这种类型的体系结构基本上包括：

• 瘦服务器，只是一个无头api，它：
  • 处理安全问题

  • 处理核心业务逻辑

  • 提供数据持久性

• 胖客户端，具有类似桌面的设计，可：
  • 缓存数据，并使脱机使用成为可能

  • 具有gui模板和呈现功能

  • 保存和处理非关键业务逻辑

然而，乍一看，这样的体系结构并不能很好地适应当今的网络工作方式：

当javascript不可用时，回退能力很差或没有可能（现在有2%的用户代理，对吗？）

• 可访问性问题（我在这里有点不知所措）

• 就SEO而言，cloacking是一个选项，但这意味着应该提供一些服务器端html呈现，并且使内容相关可能很棘手

我还缺什么？ 您会采取哪种方法来解决这些问题？

• 要么是JavaScript，要么是Flex（最好是JS）。在我看来，这2%完全可以忽略不计
• 可访问性-，它仍在进行中，但值得一看
• 搜索引擎索引内容。您将要编写一个应用程序，它关注的是功能，而不是内容。您可以有一个打开的纯html屏幕，可以对其进行索引

---

REST允许为Web应用程序和桌面应用程序轻松创建此类体系结构
在这里，REST服务器将响应HTTP请求（GET、POST、DELETE等），执行CRUD操作以实现持久性，最有可能的是业务核心规则和安全性
在更大的系统中，可以使用“协调器”聚合多个REST服务器，以处理事务等问题
在此之上，UI层将使用HTML、AJAX或其他工具向客户机进行实际演示
这种方法的最大优点是：
• 它是可伸缩的。REST持久性和协调层是无状态的，因此可以引入额外的服务器来处理更大的负载

• 数据持久性、安全性和业务逻辑被整齐地封装在UI之外

• 可以合理简单地为不同的情况创建不同的UI，例如，精简手机UI等

缺点包括：
• 它相对较新，因此缺乏工具支持（尤其是在Microsoft领域）

• 大型系统的部署可能会变得复杂，因为可能存在大量的服务相互依赖关系

---

希望这能有所帮助，
很好的链接，但是我仍然希望能够将一些动态内容编入索引，不太确定如何实际做到这一点。您可以为动态内容提供静态链接。是的，这些是这种体系结构的一些优点。然而，我的问题是，在某些用例中，它是如何不足的。@julien-在哪些用例中？特别是，可访问性和JavaScript是站点UI设计的一个方面，而不是底层持久性机制的一个方面。您的瘦服务器不应该是UI，因此SEO在这里也不是问题。