这是“反模式”吗，我应该停止使用它还是这个聪明的设计？

10

创建REST服务时，我基本上已经注视着要执行以下操作：

要求HTML
服务返回所需的网页，但没有请求的“资源”，例如。数据
网页包含向同一服务发出AJAX请求的JavaScript（不同的内容类型）
服务然后返回实际数据（JSON），然后页面将其显示

一方面，它似乎效率低下（2个请求），但后来我用了它，“性能无关紧要”，这意味着内部应用程序和网站的低流量运行非常简单且加载速度很快。

我之所以这样做，是因为该网页几乎可以是纯HTML + JavaScript的，几乎不需要服务器端的东西，尤其是不需要循环，就可以创建表和类似的东西（与之相比，我觉得这很丑陋）诸如slickgrid之类的东西），例如数据和视图的分离。

现在，在我开始使用它之前，这是个好主意还是应该停止这样做？

web-services rest anti-patterns

— 初学者_
source

2

如果您想花更多的时间与亲人在一起，并且希望有空闲时间来享受自己的爱好或追求个人目标，那么看在上帝的份上：不要编写像这样的应用程序！但是，如果您喜欢在办公室的晚上和周末熬夜，维护大量的“聪明”代码，那么适合自己。

— TulainsCórdova13年

3

您能具体说明您认为不好的地方吗？背景信息：这不是10 Mio LOC的野兽，对商业至关重要。它更像是<5000 LOC，并且不管几天不工作都没关系。是的，那不是我应该做的烂事，因此，要淡化您认为如此糟糕的事情。

— 初学者

@begginer_每个软件从小处开始。你描述rseembles一个鲁布·戈德堡机械什么：槌敲击男人，男人下降饼干，鹦鹉抢饼干和倾斜花瓶等

— Tulains科尔多瓦

这样做的原因通常是为了提高性能，在这种情况下，可以同时向可能是不同服务器的多个请求发送数据。这似乎不适用于您的情况。

— user16764 2013年

您如何从客户端（例如脚本）或curl中使用此服务？这些东西没有javascript解释器。这是仅用于浏览器的服务吗？

— Bryan Oakley

17

如果您请求的资源不包含数据，则它不是REST服务。提供json中实际数据的服务可能是，但HTML部分却没有。对于Web应用程序，这无关紧要。

该技术有效，但是您需要意识到它的局限性：

搜索引擎不会解释JavaScript，因此类似网站的实现不会被Google等索引。对于内部应用而言，这并不重要，对于面向公众的应用而言，则非常重要。
有特殊需求的用户（例如使用盲文终端的用户）使用的特殊浏览器非常有限，可能无法正确解释JavaScript。

我还要注意，无论运行服务器端还是客户端，生成HTML的代码基本相同。您可以在服务器端同时选择语言和框架，而且我敢肯定还有slickgrid的几种等效产品。

您可以并且应该仍然保持数据分离并在服务器端显示。模板系统可以并且应该简单地将数据作为数据结构甚至json（特别是如果实际服务使用的语言与模板系统不同），并仅使用该数据扩展模板。

不，我不是在考虑PHP。这是目前功能最差的模板系统（尽管在其之上构建了一些更好的模板系统）。我在想Genshi或XSLT或什至更高级的提供Web小部件的东西。

— 扬·胡德克（Jan Hudec）
source

我用JavaScript编写fat-clients，正是这样做的。但这对于普通网站可能不是一个好主意。

— K。。

为什么不是REST？

— dagnelies 2013年

1

如果您区分构成应用程序的“数据”（HTML，JS，CSS等）和应用程序显示的“数据”（JSON），则JSON部分为REST，而加载“代码”的部分为' t。如果您将整个事情看得更抽象，那么两者都是。

— K..13年

2

只要您确保干净地构造代码，这样做就没有错。您甚至可以从例如Apache而不是从Web服务提供静态内容。

— 史蒂文·史兰斯克
source

2

对于静态内容，Apache过于矫kill过正。有更快的服务器。最受欢迎的似乎是Nginx。

— Jan Hudec

5

那只是一个例子，仅此而已。

— 史蒂文·斯兰斯克

2

这是一个好习惯。就像@JanHudec指出的那样，它一直都在做，称其为REST服务是错误的。但是，许多网站正是出于您指出的原因而这样做的。

— 罗斯·帕特森
source

1

...也是很多人这样做的主要原因是因为无论如何数据交互都是通过服务/ JSON进行的，因此最好以相同的方式处理所有数据交互。（即，如果您正在使用AJAX刷新表...也应该首先使用它来构建表。）

— Chad Thompson

@ChadThompson是的，我发现很多时候，如果我首先不构建这样的东西，那么在某个地方，我会收到一个功能请求，该功能请求是基于客户端的行为来动态更新页面的-意味着一个简单的实现现在可以使客户端和服务器都知道如何构建页面。首先，将其构建在客户端上会更容易。

— Tacroy

1

我不会称其为反模式，您所描述的或多或少是一个胖客户端，与Trello等服务完全不同。服务器的最初职责是发送DOM和使客户端工作所需的任何资源。我曾在数据中心自动化和网络监控领域从事过类似的项目。

客户端以稀疏DOM开头，通过XHR（有时通过JSONP）提取一些数据，最后将其自身附加到套接字服务器。一个更基本的示例是聊天应用程序。

不这样做的唯一原因是，很难正确地做到这一点。如果您对异步函数式编程以及它可能带来的所有竞争和其他挑战感到满意，那么您就可以毫无问题地维护它。更重要的是，编写它不会有任何问题，以便其他人最终可以维护它。

如果添加更多功能的想法开始使您感到恐惧，或者您开始发现调试是一场噩梦，那么在继续尝试和学习的同时，您可能想考虑生产中的其他方法。

只要您不自己挖坑，这就是有效的设计。如果到处都是随机JS的小滴和小滴，而不是干净的接口，那么您可能想要重构或以其他方式处理项目。定义为在所有资源加载后立即执行的大多数函数应该是匿名的，并从干净的界面输入。如果不是，您可能会遇到麻烦。

— 蒂姆邮政
source

您所说的“随机JS”是什么意思？就我而言，您在上面描述的内容要复杂得多（一些输入字段和一个表（slickgrid）或jquery ui选项卡）。这就对了。每页约200个LOC。

— 初学者

0

正如@Jan Hudec所说，您的方法绝对不能称为REST。尽管客户端请求资源的部分可能是。最好让客户像backbone这样处理呈现部分。它与REST服务器通信以获取资源，并使用显示它们views。

— Broncha
source

0

这可能是一种反模式，但我认为这也是Web应用程序的未来。但是，您应该至少使用模板库，而不是搞砸JavaScript。更好的解决方案是像AngularJS这样的客户端MVC框架（我碰巧现在正在使用）。

有关更多参考，这是一个流行的博客文章，比较了多个框架，这是一个使用多个框架实现相同程序的站点。

另外：Jan Hudec关于搜索引擎交互和屏幕阅读器的评论是有效的。如果您在电子商务站点（页面排名很重要）上工作，那么您可能不想使用客户端框架。但是对于内部应用程序，通常不需要担心。

— 异质的
source

thx从未听说过AngularJS。但是我认为对于我当前的需求来说太多了。

— 初学者

0

你的所作所为听起来不错！但是，如果您的json响应包含任何HTML，那么您将浪费时间。

不过，还有一点是，您的笨客户端可能应该从其他项目中获取其json数据。您应该将客户端和服务之间的适当分离作为目标，然后您将获得适当的RESTful服务

— 基思·平科姆
source