Separate REST JSON API server and client? [closed]

2019-05-17 10:46发布

站内文章 / 前端开发
36 0 0

我要从头开始创建一批网络应用程序。 （见http://50pop.com/code的概述。）我想对他们能够从许多不同的客户端访问：前端网站，智能手机应用程序，后台web服务，等等。所以我真的想要一个JSON REST API的每一个。

另外，我喜欢工作的后端，所以我遐想我保持我的焦点纯粹的API，并雇用别人来使前端用户界面，无论是网站，iPhone，Android或其他应用程序。

请帮我决定我应该采取哪一种方法：

一起钢轨

做一个非常标准的Rails Web的应用程序。 在控制器中，做respond_with开关，以服务JSON或HTML。 JSON响应然后我的API。

临：先例很多。 大标准及处事这样的例子很多。

缺点：不一定要API是相同的Web应用程序。 不喜欢的if / then respond_with开关的方法。 混合两种完全不同的事情（UI + API）。

REST服务器+ JAVASCRIPT重CLIENT

做一个只JSON，REST API服务器。 使用骨干或Ember.js对客户端JavaScript直接访问API，在浏览器中显示的模板。

利：我爱API和客户端的分离。 聪明的人说这是要走的路。 伟大的理论。 似乎尖端和令人兴奋的。

缺点：没有太多的先例。 这样的例子并不多做得很好。 公共实例（twitter.com）迟缓的感觉和甚至开关从这种方法了。

REST服务器+服务器端的HTML客户端

做一个只JSON，REST API服务器。 做一个基本的HTML网站的客户端，只访问REST API。 少客户端JavaScript。

利：我爱API和客户端的分离。 但是，服务普通HTML5是相当简单的与客户端不密集。

缺点：没有太多的先例。 这样的例子并不多做得很好。 框架不支持这一点。 不知道如何处理它。

特别是寻找来自经验，不仅在理论建议。

Answer 1:

在大千世界 ，我们已经走了深与选项＃2和轧出来给成千上万的学生。 我们的服务器是一个JSON REST API（斯卡拉+ MongoDB的），和我们所有的客户端代码投放直出CloudFront的（即：www.boundless.com仅仅是一个CloudFront的别名）。

优点：

  • 新锐/激动人心
  • 很多爆炸为您的降压的：API为您提供了依据自己的网络客户端，移动客户端，第三方接入等
  • 非常快速的网站加载/网页过渡

缺点：

  • 不是搜索引擎友好/没有准备好大量的工作。
  • 需要一流的Web前端民间谁准备，以应付瓦特/的现场经验，是70％的JavaScript和这意味着什么现实。

我认为这是所有网络应用的未来。

一些思考web前端人（这是所有新的烦躁/挑战给出该架构）：

  • CoffeeScript的。 更容易生产出高质量的代码。
  • 骨干。 伟大的方式来组织你的逻辑，以及活跃的社区。
  • HAMLC。 HAML + CoffeeScript的模板=> JS。
  • 上海社会科学院

我们已经建立了所谓的“晶石”（单页应用飞船）为我们的前端开发线束，有效地从滑轨资产管道调整为单个页面应用程序开发。 我们将我们对未来几周内开放式采购GitHub的页面，用博客文章，解释如何使用它和整体架构更加详细一起。

更新：

对于人们的关注与骨干，我认为他们是高估的。 骨干远不止是一个深刻的框架的组织原则。 Twitter的网站本身就是JavaScript的一个巨型兽覆盖在数百万用户和传统浏览器的每一个角落情况下，同时加载微博实时，垃圾收集，显示大量的多媒体的，等所有的“纯” JS网站我已经中看出，Twitter是奇数一个出来。 已经有通过JS发表过许多令人印象深刻复杂的应用程序，票价非常好。

和你的架构的选择完全取决于你的目标。 如果您正在寻找支持多个客户端，并有机会获得良好的前端人才以最快的方式，在一个独立的API的投资是一个伟大的路要走。



Answer 2:

很好地问道。 +1。 可以肯定，这是对我将来有用的参考。 此外@Aaron和其他附加价值的讨论。 像Ruby，这个问题同样适用于其他编程环境。

我已经使用了前两个选项。 第一个为众多应用和第二个对我的开源项目Cowoop

选项1

这一次无疑是最受欢迎的一个。 但我发现执行都非常HTTP十岁上下。 每个API的初始代码放在处理请求对象。 所以API代码比纯Ruby / Python的/其他语言的代码更。

选项2

我一直很喜欢这一点。

这个选项也意味着不支持HTML代码运行在服务器上生成。 这是选项2是如何从选项3不同，但建立使用构建脚本作为静态的HTML。 当客户端加载这些HTML将调用API服务器JS API客户端。

  • 关注点分离是很大的优势。 而且很符合自己的喜好（和我）的后端专家实施后端的API，很容易像往常一样的语言代码，测试它们，而不必担心框架/ HTTP请求的代码。

  • 因为它的声音在前端侧这个真没有那么难。 做API调用和产生的数据（主要是JSON）是提供给您的客户端模板或MVC。

  • 较少的服务器端处理。 这意味着你可以去的商品硬件/更便宜的服务器。

  • 更容易独立地测试层，更容易产生API文档。

它也有一些缺点。

  • 许多开发人员发现这种过度设计，很难理解。 所以机会是结构可能会受到批评。

  • 国际化/本地化是很难的。 由于HTML基本上产生编译时间是静态的，需要每所支持的语言（这不一定是坏事）多个版本。 但是，即使你可能有各地的本地化/ i18n的角落案件，需要小心。

选项3

在这种情况下后端编码必须是相同第二个选项。 选项2的最高分是适用在这里。

网页使用服务器端模板呈现运行。 这使得国际化/本地化与更为成熟的/接受的技术要容易得多。 可能是少了一个HTTP调用了需要的页面渲染，如用户，语言，货币等一些必要的背景所以服务器端处理与呈现增加，但可能由少HTTP调用API服务器补偿。

现在，页面呈现在服务器上的服务器，前端现在更并列的编程环境。 这可能不是甚至成为许多应用的考虑。

Twitter的情况下，

据我所知，微博的威力确实在服务器的初始页面渲染但页面更新它仍然有一些API调用和客户端模板来操作DOM。 因此，在这种情况下，你有双重的模板，以保持它增加了一些开销和复杂性。 不是每个人都买得起这个选项，不像Twitter的。

我们的项目堆栈

我碰巧使用Python。 我用JsonRPC 2.0，而不是REST。 我建议休息，但我喜欢以各种理由JsonRPC的想法。 我用下面的库。 有人考虑选择2/3可能会发现它很有用。

  • API服务器：Python中的快速的网络微架构- 瓶
  • 前端服务器：Nginx的
  • 客户端MVC： Knockout.js
  • 其他相关工具/库：
    • jQuery的
    • Accounting.js货币汇率
    • Webshim ：跨浏览器的填充工具
    • 导演 ：客户端路由
    • SPHC ：HTML生成

我的结论和建议

选项3！

尽管如此，我已经使用选项2成功，但现在倾向于对一些简单的选项3。 生成与构建脚本静态HTML页面，并与专注于提供静态页面的超快速的服务器的一个为他们服务是非常具有诱惑力（选项2）。



Answer 3:

建设gaug.es.时，我们选择了＃2 我的工作是API（红宝石，西纳特拉等）和我的商业伙伴，史蒂夫·史密斯，在前端（JavaScript客户端）工作。

优点：

  1. 在平行快速移动。 如果我前面工作的史蒂夫，我可以继续创造新功能的API。 如果他的工作我的未来，他可以伪造出来的API很容易和构建UI。

  2. API是免费的。 拥有开放访问您的应用程序中的数据正迅速成为一个标准功能。 如果你开始从地上爬起来的API，你得到这个免费的。

  3. 干净的分离。 这是更好地认为你的应用程序与客户端的API。 当然，第一个和最重要的客户端可以是网络，但它设置你轻松创建其他客户端（iPhone和Android）。

缺点：

  1. 向后兼容性。 这更多的与比你直接问一个API，但一旦你的API就在那里，你不能打破它，或者你打破所有的客户端两项。 这并不意味着你必须移动速度较慢，但​​它确实意味着你必须经常做两件事情马上开始工作。 添加到API或新的领域是好的，但改变/删除不应该在没有版本控制来完成。

我现在不能想了利弊。

结论：API + JS客户端，如果你打算发布一个API的路要走。

PS我也建议完全释放之前，记录您的API。 记录Gaug.es API的过程中真正帮助我们小鬼

http://get.gaug.es/documentation/api/



Answer 4:

我更喜欢去的＃2，＃3的路线。 主要是因为＃1违反了关注点分离和intermingles各种东西。 最终你会发现，需要有一个不具有匹配的HTML页面的/ etc的API终点，你就可以了一条小溪，在相同的代码库;混合HTML和JSON的端点。 它变成了乱七八糟再用，即使其MVP，你必须把它最终因为其洙凌乱，它甚至不值得挽救重新写。

与2＃或＃3去让你完全有不管的作用是相同的（大部分）一个API。 这提供了极大的灵活性。 我不是100％的骨干/烬/只是还没有什么/ etc.js出售。 我认为它的伟大，但我们正在与Twitter的看到这是不是最佳的。 但是... Twitter的也是公司的一个巨大的野兽，拥有数亿用户。 因此，任何改善能够对各业务单位的各个领域的底线产生巨大影响。 我想有更多的比单独的速度决定，他们没有让我们在这一点。 但那只是我的个人意见。 不过，我不打折骨干网和它的竞争对手。 这些应用程序是伟大的使用，而且非常干净，是非常敏感（大部分）。

第三个选择有一些有效的吸引力，以及。 这是我遵循帕累托原则（80/20法则），让您的主要标记（反之亦然）的20％，提供的服务器上，然后有一个很好的JS客户端（骨干网/等）运行它的其余部分。 你可能不被通过的JS客户端的REST API通信100％，但你会做一些工作，如果有必要，使经验发售者更好。

我觉得这是那些“这取决于”各种问题的一个答案是“这取决于”你在做什么，谁你服务什么样的经验，你希望他们接受。 鉴于我认为你可以2或3或它们的混合体之间做出选择。



Answer 5:

我目前正在从选项1转换一个巨大的CMS选项3，而且进展顺利。 我们选择呈现标记的服务器端，因为SEO是什么大不了的事给我们，我们想要的网站在手机上表现良好。

我使用客户端的后端和模块屈指可数的node.js来帮助我。 我在这个过程中有些早，但基础设置和它的渡过了数据保证这一切使得一个权利问题。 下面是我使用的是什么：

  • 表达对应用程序的基础。
    （https://github.com/visionmedia/express）
  • 请求获取数据。
    （https://github.com/mikeal/request）
  • 强调的是得到渲染服务器端模板。 我重用这些客户端上。
    （https://github.com/documentcloud/underscore）
  • UTML包装下划线的模板，以使它们与快递工作。
    （https://github.com/mikefrey/utml）
  • 前期收集的模板，让你选择的这被发送到客户端。
    （https://github.com/mrDarcyMurphy/upfront）
  • 表达暴露传递所取得的数据，一些模块，并以前端模板。
    （https://github.com/visionmedia/express-expose）
  • 骨干吞下相处传递的数据后创建的前端模型和视图。
    （https://github.com/documentcloud/backbone）

这是堆栈的核心。 其他一些模块，我发现有帮助：

  • 斑点（HTTPS // github.com /跋涉/斑点）
  • 瞬间（HTTPS // github.com / timrwood /力矩）
  • 触针（HTTPS // github.com / LearnBoost /触笔）
  • smoosh（HTTPS // github.com /脂肪/ smoosh）
    ......虽然我寻找到咕噜（HTTPS // github.com /牛仔/咕噜）
  • 控制台跟踪（//github.com/LearnBoost/console-trace）。

不，我没有使用CoffeeScript的。

该选项的工作对我很好。 在后端的机型是不存在的，因为我们从API得到的数据是结构良好，我将其传递到逐字前端。 唯一的例外是我们的布局模型，其中我添加了一个单独的属性，使得渲染更聪明，更轻。 我没有使用任何花哨的模型库，只是增加了什么，我需要在初始化并返回自身的函数。

（对不起，奇怪的链接，我太的n00b的堆栈溢出，让我张贴许多）



Answer 6:

我们使用的＃3以下的变体：做一个只JSON，REST API服务器。 做一个HTML的网站服务器。 在HTML Web服务器没有，在你的变体，将客户端的REST API服务器。 相反，两者是对等体。 不远处的表面之下，存在提供了两个服务器所需要的功能的内部API。

我们不知道任何先例的，所以它是一种实验性的。 到目前为止（即将进入测试版）​​，它已经制定了相当不错。



Answer 7:

我通常会在第二个选项，使用Rails构建的API，并为骨干JS的东西。 你甚至可以得到一个管理面板免费使用ActiveAdmin 。 我已经出货数万移动应用与这种后端。 然而，它在很大程度上取决于如果你的应用是互动与否。

我做了这个方法介绍在最后RubyDay.it ： http://www.slideshare.net/matteocollina/enter-the-app-era-with-ruby-on-rails-rubyday

对于第三个选项，以获得第二届一个的反应，你可能会想尝试pajax为Github上一样。



Answer 8:

我大约2个月到3个月的项目，它需要你在这里列出的第二种方法。 我们使用一个RESTful API服务器端与前面Backbone.js的。 Handlebars.js管理模板和jQuery处理AJAX和DOM操作。 对于较旧的浏览器和搜索蜘蛛，我们已经回落到服务器端渲染，但我们使用相同的HTML模板，因为使用Mozilla Rhino的把手前端。

我们选择这种方法的原因有很多，但都非常清楚这是一个有点冒险给它没有被证明在广泛的规模呢。 所有终端设备相同的，一切都会相当顺利至今。

到目前为止，我们刚刚一直在与一个API，但在项目的下一阶段，我们将与第二API来工作。 第一个是对大量的数据，并经由API第二更像一个CMS。

有了这两个完全相互独立的项目动作片是在选择这个基础设施的关键考虑因素。 如果你正在寻找一个架构来混搭不同的独立资源，而不依赖任何那么这个做法是值得一试。

我怕我不是一个Ruby的家伙，所以我不能对其他方法发表评论。 有时，它的好承担风险。 其他时候，它更好地发挥它的安全。 您可以根据项目的K型流自己。

祝您好运与您所选择这里。 敏锐地看到了别人，以及分享。



Answer 9:

我喜欢＃3时，我的网站不会是一个100％的CRUD实现我的数据。 这一点还没有发生。

我更喜欢西纳特拉和只会分裂应用到具有不同用途的几个不同的机架应用程序。 我会做一个API特定机架的应用程序，将覆盖什么，我需要的API。 然后，用户也许架的应用程序，将提出我的网页。 有时，如果需要的版本会查询API，但通常只是关注自身与HTML的网站。

我不担心，只是做一个持久化层查询从用户侧，如果我需要它。 我并不过分关注与创建一个完全分离的，因为他们通常最终服务于不同的目的。

下面是使用多架应用的一个非常简单的例子。 我在里面加了快速的jQuery的例子给你看它击中API的应用程序。 你可以看到它是多么简单与西纳特拉和安装有多个不同用途的机架应用程序。

https://github.com/dusty/multi-rack-app-app



Answer 10:

这里的一些伟大的答案已经 - 我肯定会推荐＃2或＃3 - 的分离是好的概念，而且在实践中。

它可以是很难预测的东西像负载和业务模式上的API，我们看到客户谁独立服务API有供应和缩放的时候更容易。 如果你有这样做，被改写的与人的网络访问模式是不容易。 此外API的使用最终可能会比你的Web客户端扩大速度快了很多，然后你可以看到自己努力的方向。

之间＃2＃3这真的取决于你的目标 - 我同意＃2可能是Web应用程序的未来 - 但也许你想要的东西更简单，如果该通道只会是许多之一！



Answer 11:

对于atyourservice.com.cy我们使用服务器端渲染的模板页面尤其是覆盖部分本身。 并使用API​​的页面加载后的相互作用。 由于我们的框架是MVC控制器的所有功能都复制到JSON输出和HTML输出。 模板是干净的，而只接收的对象。 这可以在几秒钟内转化为JS模板。 我们始终保持服务器端模板，只是再转换成JS的请求。



Answer 12:

同构渲染和渐进增强。 这是我想你在选项三人前往。

同构渲染使用相同的模板，你在客户端代码中使用生成标记的服务器端方法。 挑选具有良好的服务器端和客户端实现一个模板语言。 为用户创建完全成熟的HTML和发送下来的电线。 使用高速缓存过多。

渐进增强指开始做客户端执行和呈现，并侦听事件一旦你下载了所有的资源，你可以决定一个客户端功能。 回落到功能客户端脚本，更少的功能尽可能的方便性和向后兼容性。

是的，当然写这个程序的功能独立的JSON API。 但是不要到目前为止，你写的东西，就可以作为静态HTML文档的JSON API去。



Answer 13:

REST服务器+ JavaScript的沉重的客户是我跟着我最近的工作原理。

REST服务器在执行的node.js + 快速 + MongoDB的 （非常良好的书写性能）+ 猫鼬ODM （伟大的建模数据，验证含税）+ CoffeeScript的这对我来说效果很好（我会去ES2015现在不是）。 相比于其他可能的服务器端技术的Node.js可能是相对年轻，但它使人们有可能对我来说，写与集成支付固体API。

我用Ember.js的JavaScript框架和大部分应用程序逻辑是在浏览器中执行。 我用SASS （SCSS专）为CSS预处理。

灰烬是社会各界的大力支持成熟的框架。 这是正在做的，有很多的工作非常强大的框架，最近侧重于性能，如全新的微光渲染引擎 （由作出反应的启发）。

Ember公司核心团队在开发过程的FastBoot ，这让你在服务器端执行你的JavaScript灰烬逻辑（node.js中明确），并发送您的应用程序的预渲染HTML（这通常会在浏览器中运行）用户。 因为他不会等待这么长的时间来显示页面这是伟大的搜索引擎优化和用户体验。

灰烬CLI是伟大的工具，可以帮助你组织你的代码，它表现很好，规模不断增长的代码库。 Ember公司也有它自己的插件生态系统，你可以从不同的选择灰烬附加组件 。 您可以轻松抓取自举（在我的情况）或基金会，并将其添加到您的应用程序。

不服务通过快递的一切，我已经选择使用nginx的服务为图像和JavaScript重的客户端。 使用nginx的代理在我的情况有所帮助： 

upstream app_appName.com {
  # replace 0.0.0.0 with your IP address and 1000 with your port of node HTTP server
  server 0.0.0.0:1000;
  keepalive 8;
}

server {
  listen 80 default_server;
  listen [::]:80 default_server ipv6only=on;

  client_max_body_size 32M;

  access_log  /var/log/nginx/appName.access.log;
  error_log  /var/log/nginx/appName.error.log;

  server_name appName.com appName;

  location / {
     # frontend assets path
     root /var/www/html;
     index index.html;

     # to handle Ember routing
     try_files $uri $uri/ /index.html?/$request_uri;
  }

  location /i/ {
    alias /var/i/img/;
  }

  location /api/v1/ {
    proxy_pass  http://app_appName.com;

    proxy_next_upstream error timeout invalid_header http_500 http_502
http_503 http_504;
    proxy_redirect off;
    proxy_buffering off;
    proxy_set_header        Host            $host;
    proxy_set_header        X-Real-IP       $remote_addr;
    proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
  }
}

利：我爱API和客户端的分离。 聪明的人说这是要走的路。 伟大的理论。 似乎尖端和令人兴奋的。

我可以说这是也是伟大实践中。 分离REST API的另一个优点是，你可以在以后重新使用它的另一个应用程序。 在完美的世界里，你应该能够使用相同的REST API不仅对网页，同时也为移动应用程序，如果你决定自己写一个。

缺点：没有太多的先例。 这样的例子并不多做得很好。 公共实例（twitter.com）迟缓的感觉和甚至开关从这种方法了。

现在情况有所不同。 有很多做的REST API +许多客户消费它的例子。



Answer 14:

我决定去的选项＃2的架构Infiniforms ，因为它提供了一个很好的方式向用户界面从业务逻辑分离。

这样做的好处是，API服务器可以独立于Web服务器的规模。 如果你有多个客户端，那么网站将不再需要扩展到相同的程度作为Web服务器，如一些客户泔水是基于手机/平板电脑或台式机。

这种做法也给你的API开放给用户，特别是如果你使用自己的API来提供所有的功能，为您的网站了良好的基础。



Answer 15:

然而，一个非常好的问题，我很惊讶，因为我以为这是一个很常见的任务现在这样，我将有大量针对这个问题的资源，竟然是不正确的。

我的想法如下： -创建一些模块有API控制器和HTML控制器之间的共同逻辑，而无需返回JSON或渲染HTML，并包括以HTML控制器和API控制这个模块，然后做你想做的，因此，例如： 

module WebAndAPICommon
    module Products

        def index
            @products = # do some logic here that will set @products variable
        end

    end
end


class ProductsController < ApplicationController
    # default products controlelr, for rendering HMTL pages 
    include WebAndAPICommon

    def index
        super
    end

end



module API
    class ProductsController
        include WebAndAPICommon

        def index
            super
            render json: @products
        end

    end
end


Answer 16:

我已经为一种混合的方法，我们的用户西纳特拉为基地，ActiveRecord的/ Postgress等就可以提供网页的路线（超薄模板）暴露REST API的web应用程序可以使用。 在早期发展的东西像填充选择的选项是通过助手绘制成苗条模板完成，但是当我们接近生产这种被换出了一个AJAX调用一个REST API，因为我们开始更关心的页面加载速度，等等。

的东西，很容易呈现出在斯利姆被处理这种方式，和东西（填充的形式，从jQuery.Validation的接收表单POST数据submitHandler等，是所有abviously AJAX）

测试是一个问题。 现在我难倒试图通过JSON数据机架::测试后的测试 。



Answer 17:

我个人比较喜欢的选择（3）作为解决方案。 它在几乎所有的网站我的前任（家喻户晓）雇主使用。 这意味着，你可以得到一些前端开发者谁知道所有有关的Javascript，浏览器的怪癖和诸如此类的东西编写你的前端。 他们只需要知道“卷曲某某，你会得到一些JSON”和走人。

同时，你的重量级后端家伙可以编写的JSON提供商。 这些人并不需要在所有想到的介绍，而是担心片状后端，超时，优美的错误处理，数据库连接池，线程和缩放等。

方案3为您提供了一个良好的，坚实的三层架构。 这意味着你吐出前端的东西，是搜索引擎友好的，可以由旧的或新的浏览器工作（和那些JS关闭），并可能仍然是JavaScript客户端模板，如果你想要的（所以你可以做这样的事情处理旧的浏览器/静态HTML Googlebot的，但发送JS内置的动态体验，采用了最新的Chrome浏览器或其他）的人。

在我见过的方案3的所有情况下，它已经有些PHP不是项目之间转移的特别的自定义实现，更别说出开放源码的土地。 我猜最近PHP可能已被替换的Ruby / Rails，但同样的事情仍然是正确的。

FWIW，$ CURRENT_EMPLOYER可以做在几个重要的地方选3。 我在寻找一个良好的Ruby框架中建立的东西。 我敢肯定，我可以粘合在一起宝石的负荷，但我更喜欢一个单一的产品，广泛地提供了一种模板，“冰壶”，可选的认证，可选的内存缓存/ NoSQL的连接缓存解决方案。 还有我无法找到任何连贯:-(



Answer 18:

建立在Rails JSON API是一流的，在JSONAPI ::资源宝石做繁重的http://jsonapi.org只具备API。



文章来源: Separate REST JSON API server and client? [closed]
标签： ruby-on-rails-3 rest backbone.js sinatra ember.js
举报

收藏的人(0)

Ta的文章 更多文章
登录 后发表评论
0条评论
还没有人评论过~