分离 REST JSON API 服务器和客户端? [英] Separate REST JSON API server and client?

问题描述

我将要从头开始创建一堆网络应用程序.(有关概述，请参阅 http://50pop.com/code.)我希望他们能够可以从许多不同的客户端访问:前端网站、智能手机应用程序、后端网络服务等.所以我真的希望每个客户端都有一个 JSON REST API.

另外，我更喜欢在后端工作，所以我做白日梦，我只专注于 API，并聘请其他人来制作前端 UI，无论是网站、iPhone、Android 还是其他应用程序.

请帮助我决定我应该采取哪种方法:

<块引用>

一起在轨道上

制作一个非常标准的 Rails 网络应用程序.在控制器中，执行 respond_with 开关，以提供 JSON 或 HTML.JSON 响应就是我的 API.

优点:有很多先例.伟大的标准和以这种方式做事的例子很多.

缺点:不一定希望 API 与网络应用程序相同.不喜欢 if/then respond_with 切换方法.混合两种截然不同的东西(UI + API).

<块引用>

REST 服务器 + JAVASCRIPT-HEAVY 客户端

制作仅 JSON 的 REST API 服务器.客户端JavaScript使用Backbone或Ember.js直接访问API，在浏览器中展示模板.

优点:我喜欢 API 和 API 的分离.客户.聪明的人说这是要走的路.理论上很棒.看起来前沿且令人兴奋.

缺点:没有多少先例.这方面做得好的例子并不多.公开的例子(twitter.com)感觉呆滞&甚至正在放弃这种方法.

<块引用>

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

制作仅 JSON 的 REST API 服务器.制作一个基本的 HTML 网站客户端，仅访问 REST API.减少客户端 JavaScript.

优点:我喜欢 API 和 API 的分离.客户.但是提供纯 HTML5 是非常万无一失的 &不是客户密集型的.

缺点:没有多少先例.这方面做得好的例子并不多.框架也不支持这一点.不知道如何处理.

特别是从经验中寻求建议，而不仅仅是理论上.

解决方案

在 Boundless，我们深入研究了选项 #2 并推出了它给成千上万的学生.我们的服务器是一个 JSON REST API(Scala + MongoDB)，我们所有的客户端代码都是直接从 CloudFront 提供的(即:www.boundless.com 只是 CloudFront 的别名).

优点:

• 前沿/激动人心
• 物超所值:API 为您自己的网络客户端、移动客户端、第三方访问等提供了基础.
• 极速网站加载/页面转换

缺点:

• 没有更多的工作，对 SEO 不友好/准备就绪.
• 需要一流的网络前端人员，他们准备好应对 70% 是 javascript 的网站体验的现实以及这意味着什么.

我确实认为这是所有网络应用的未来.

给 Web 前端人员的一些想法(所有新事物/挑战都来自此架构):

• 咖啡脚本.更容易生成高质量的代码.
• 骨干.组织逻辑和活跃社区的好方法.
• HAMLC.Haml + CoffeeScript 模板 => JS.
• SASS

我们为前端开发构建了一个名为Spar"(单页应用火箭飞船)的工具，它实际上是来自 Rails 的资产管道，针对单页应用开发进行了调整.我们将在接下来的几周内在我们的 github 页面上开放源代码，以及一篇解释如何使用它和整体的博客文章更详细的架构.

更新:

关于人们对 Backbone 的担忧，我认为他们被高估了.Backbone 与其说是一个深层框架，不如说是一种组织原则.Twitter 的网站本身就是一个巨大的 Javascript 野兽，涵盖了数百万用户的每一个角落.旧浏览器，同时实时加载推文、垃圾收集、显示大量多媒体等.在我见过的所有纯"js 站点中，Twitter 是一个奇怪的站点.有许多通过 JS 交付的令人印象深刻的复杂应用程序运行良好.

您对架构的选择完全取决于您的目标.如果您正在寻找最快的方式来支持多个客户并获得优秀的前端人才，那么投资于独立的 API 是一个不错的选择.

I'm about to create a bunch of web apps from scratch. (See http://50pop.com/code for overview.) I'd like for them to be able to be accessed from many different clients: front-end websites, smartphone apps, backend webservices, etc. So I really want a JSON REST API for each one.

Also, I prefer working on the back-end, so I daydream of me keeping my focus purely on the API, and hiring someone else to make the front-end UI, whether a website, iPhone, Android, or other app.

Please help me decide which approach I should take:

TOGETHER IN RAILS

Make a very standard Rails web-app. In the controller, do the respond_with switch, to serve either JSON or HTML. The JSON response is then my API.

Pro: Lots of precedent. Great standards & many examples of doing things this way.

Con: Don't necessarily want API to be same as web app. Don't like if/then respond_with switch approach. Mixing two very different things (UI + API).

REST SERVER + JAVASCRIPT-HEAVY CLIENT

Make a JSON-only REST API server. Use Backbone or Ember.js for client-side JavaScript to access API directly, displaying templates in browser.

Pro: I love the separation of API & client. Smart people say this is the way to go. Great in theory. Seems cutting-edge and exciting.

Con: Not much precedent. Not many examples of this done well. Public examples (twitter.com) feel sluggish & are even switching away from this approach.

REST SERVER + SERVER-SIDE HTML CLIENT

Make a JSON-only REST API server. Make a basic HTML website client, that accesses the REST API only. Less client-side JavaScript.

Pro: I love the separation of API & client. But serving plain HTML5 is quite foolproof & not client-intensive.

Con: Not much precedent. Not many examples of this done well. Frameworks don't support this as well. Not sure how to approach it.

Especially looking for advice from experience, not just in-theory.

解决方案

At Boundless, we've gone deep with option #2 and rolled it out to thousands of students. Our server is a JSON REST API (Scala + MongoDB), and all of our client code is served straight out of CloudFront (ie: www.boundless.com is just an alias for CloudFront).

Pros:

• Cutting-edge/exciting
• A lot of bang for your buck: API gives you basis for your own web client, mobile clients, 3rd party access, etc.
• exceedingly fast site loading / page transitions

Cons:

• Not SEO friendly/ready without a lot more work.
• Requires top-notch web front-end folk who are ready to cope w/ the reality of a site experience that is 70% javascript and what that means.

I do think this is the future of all web-apps.

Some thoughts for the web front end folks (which is where all the new-ness/challenge is given this architecture):

• CoffeeScript. Much easier to produce high-quality code.
• Backbone. Great way to organize your logic, and active community.
• HAMLC. Haml + CoffeeScript templates => JS.
• SASS

We've built a harness for our front-end development called 'Spar' (Single Page App Rocketship) which is effectively the asset pipeline from Rails tuned for single page app development. We'll be open-sourcing within the next couple of weeks on our github page, along with a blog post explaining how to use it and overall architecture in greater detail.

UPDATE:

With respect to people's concerns with Backbone, I think they are over-rated. Backbone is far more an organizational principle than it is a deep framework. Twitter's site itself is a giant beast of Javascript covering every corner-case across millions of users & legacy browsers, while loading tweets real-time, garbage collect, display lots of multimedia, etc. Of all the 'pure' js sites I've seen, Twitter is the odd one out. There have been many impressively complicated apps delivered via JS that fare very well.

And your choice of architecture depends entirely on your goals. If you are looking for the fastest way to support multiple clients and have access to good front-end talent, investing in a standalone API is a great way to go.

这篇关于分离 REST JSON API 服务器和客户端?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！