单独的REST JSON API服务器和客户端？ [英] Separate REST JSON API server and client?
问题描述
另外，我喜欢在后端工作，所以我白日梦把我的焦点放在了API上，并聘请别人制作前端UI，无论是网站，iPhone，Android还是其他应用程序。
请帮我决定采用哪种方式：
TOGETHER IN RAILS
制作一个非常标准的Rails网络应用程序。在控制器中，执行respond_with开关，以提供JSON或HTML。 JSON响应就是我的API。
Pro：很多先例。伟大的标准&许多例子以这种方式做事情。
Con：不一定要使API与网络应用程序相同。不喜欢if / then respond_with切换方式。混合两个非常不同的东西（UI + API）。
REST SERVER + JAVASCRIPT-HEAVY CLIENT
制作仅JSON的REST API服务器。使用Backbone或Ember.js进行客户端JavaScript直接访问API，在浏览器中显示模板。
Pro：我喜欢分离API&客户。聪明人说这是要走的路。理论上伟大似乎是尖锐的和令人兴奋的。
Con：没有太多的先例。没有很多例子做得很好。公开示例（twitter.com）感到迟钝甚至切换这种方法。
REST SERVER + SERVER -SIDE HTML CLIENT
制作一个只有JSON的REST API服务器。制作一个基本的HTML网站客户端，只能访问REST API。较少的客户端JavaScript。
Pro：我喜欢分离API&客户。但是，提供纯粹的HTML5是非常愚蠢的不是客户密集型。
Con：没有太多的先例。没有很多例子做得很好。框架也不支持这一点。不确定如何处理。
特别寻求经验的建议，而不仅仅是理论上的。
在无边界，我们已经深入选择＃2并滚动它出来了成千上万的学生。我们的服务器是一个JSON REST API（Scala + MongoDB），我们所有的客户端代码都是直接从CloudFront（即：www.boundless.com只是CloudFront的别名）提供。
优点：
- 尖端/令人兴奋的
- 很多爆炸声为您的优势：API为您自己的网络客户端，移动客户端，第三方访问等提供了基础。
- 极端快速网站加载/页面转换<
缺点：
- 不SEO友好/准备没有更多的工作。
- 需要一流的网络前端民众，准备好应对70％javascript的网站体验现实，这意味着什么。 / li>
我认为这是所有网络应用的未来。
网络前端人士（这是所有新的/挑战都是给予这种架构）的一些想法：
- CoffeeScript。更容易生产高质量的代码。
- 骨干。很好的组织你的逻辑，积极的社区。
- HAMLC。 Haml + CoffeeScript templates => JS。
- SASS
我们的前端开发称为Spar（单页应用程序Rocketship），这是Rails针对单页应用程序开发的有效资产管道。我们将在接下来的几周内开放我们的 github 页面，并附上一篇博客文章，解释如何使用它和整体架构更详细。
更新：
关于人们对Backbone的关注，我认为他们已经结束信用等级，。主干是一个组织原则，而不是一个深层框架。 Twitter的网站本身是一个巨大的Javascript，涵盖了数百万用户和用户的每个角落。传统浏览器，同时加载Twitter实时，垃圾收集，显示大量多媒体等。在我看到的所有纯粹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屋！
