rest - REST 是 GUI Web 应用程序的好选择吗？

Question

基于 GUI 的 Web 应用程序可以构建在 GUI 组件、有状态框架(如 Wicket)上，或者它们可以以 RESTful、无状态方式构建，仅在客户端具有 GUI 状态。

从技术角度来看，REST 看起来是正确的方式，因为它充分利用了 http 的强大功能并导致高度可扩展的应用程序。但这是有代价的。在许多情况下，复杂的 GUI 将需要客户端上的 JavaScript 应用程序。如果状态应该在客户端上维护，您必须保持在同一页面上并仅重新加载部分。或者你必须使用隐藏 iframe 的技巧。有时服务器上会有购物车之类的伪资源，以启用 RESTful 设计。你必须保持多步对话的中间状态等等......

如果我环顾四周，很少有 RESTful GUI Web 应用程序。这是因为历史原因还是 RESTful 设计在常见场景中无效？

Answer 1

If I look around there are very few RESTful GUI webapplications. Is this because of historical reasons or is a RESTful design unproductive in common scenarios?

我的回答是主观的，但在我看来，阻碍 RESTful 开发的主要障碍有两个:

改变 - 它与网站的传统设计方式截然不同

挑战 - 设计纯 RESTful 服务器 API 和相应的丰富、健壮的客户端 UI 并不容易

Complex GUIs will require a JavaScript application on the client in many cases.

在我看来，无论服务器端实现如何，复杂、丰富的客户端体验都需要一些深入的 JavaScript。

You have to stay on the same page and reload only parts,

这是一个与传统的请求/响应整页到整页设计非常不同的设计。每个设计都有自己的权衡。 REST 设计特别适用于 AJAX 调用，但客户端代码需要仔细设计才能保持可维护性和健壮性。

带有胖客户端的 RESTful 服务器:

扩展性好:每个用户的 session 信息并未存储在稀缺的服务器内存中

通过线路减少请求/响应数据:不完整发送每个页面，不发送 session ID 或 ViewState s

干净的可重用 URL:提供干净、解耦的服务器 API，可以支持多个 UI

pure:严格遵守 HTTP 规范(GET 不会引起副作用等)

客户端体验:更丰富、更灵敏的异步事务

但是，正如您提到的，胖客户端有缺点:

更容易受到 XSS 攻击，RESTful URL 真的需要小心安全

复杂的 JavaScript 可能很难开发、维护和调试(使用 OO JavaScript 可以帮助解决这个问题)

需要向用户表明异步请求正在后台处理

需要更多的客户端故障处理逻辑

与服务器端相比，框架和 IDE 工具在客户端开发方面一直较弱(这正在慢慢变得更好)