restful 的一个网站设计问题

最近想尝试用restful构建新的项目,但是遇到了几个疑问点,求有经验的兄弟来帮忙解解惑.

我封装了一个restful的接口(api),那么网站html该怎么被请求/渲染呢?

我设想的是,restful单独启动一个服务,然后用nginx直接映射到template目录,然后通过api请求数据,使用前端模板进行渲染,大家是否这样子?还是有更好的方法?
在上面1的理解上上我在网上搜了下,发现了这个http://segmentfault.com/q/1010000000187725 ,大意是说刚刚的1中设想比较浪费资源,其建议是抽离出一层用于封装业务逻辑,只不过有些接口单独的提供api,一些接口负责将后端渲染好的html吐给前端.但是这个也有几点疑问:
1. 这样子需要单独维护api侧和html渲染侧,其实无非是在原来的非restful设计基础上又整理出了api接口,业务量会增加不少,似乎后期维护也会多些体力,我有些现有的代码就是这样子的.
2. 正如上侧所说,后端渲染的html页面吐给web端,web端不可避免的需要ajax请求,这个时候似乎又需要再封装一些纯吐json数据的接口,特别是在需要授权的时候,此处是通过cookie有状态的ajax请求,其与restful的无状态有概念上的一些冲突,这个ajax改怎么处理才合适?
如果大家知道开源restful项目,还请给予推荐,让俺学习学习,谢谢(以python的最佳).

learnshare

2015-04-23 15:14:29 +08:00

RESTFul 是 API，只有数据接口，跟页面毫无关系。

页面可以是静态文件（jQuery/Angular.js），然后在 JS 中请求 API 中的数据，并展示到页面中（这种方式和 App 类似，Android/iOS 与 Web 可以共享同一套 API）；
也可以是另一个后端服务，这个后端负责请求 API 并渲染页面（这样就是两个后端了）。

http://www.django-rest-framework.org/ 是一个 django 的框架，可以用来做 RESTful API。其中也附带了一个调试 API 的 Web 工具，可以参考。

gkiwi

2015-04-23 15:18:28 +08:00

@scys 谢谢.不过还是有点小问题想问下:

假设restful服务称为A,html页面我单独启一个服务(比如B)进行处理,那渲染呢?是
1. 我在B端就直接调用A服务进行渲染,然后再吐给用户
2. 还是直接将html文件扔给用户,然后在浏览器端通过js进行前端渲染?

这两个哪个比较好?

按我的理解,似乎用2比较方便,但是如此的话,登陆怎么办?因为restful没状态,我该怎么保存用户的认证呢?把认证后的token存在localStorage或者cookie中么?
求解惑:)

learnshare

2015-04-23 15:22:45 +08:00

RESTful 的 API 可以通过 token 的方式完成用户认证，就是每个登录过的用户在请求时都通过这个 token 来辨认。

>单独维护api侧和html渲染侧
是否使用 RESTful 方式，甚至是后端 API 方式，要看具体的应用场景。RESTful 只能提供访问数据库的一个个 API，使 Web/App 端可以与后端彻底分离，让第二个人单独开发都可以。如果 Web 的渲染也用后端做，那就需要两个后端（API 和渲染）来支持了。

>后端渲染的html页面吐给web端,web端不可避免的需要ajax请求
好像没有啥关系

gkiwi

2015-04-23 15:24:45 +08:00

@learnshare 谢谢.

麻烦请参考下第三条的回复, 如果再起个服务进行页面渲染的的话,那么权限认证该怎么处理好呢?因为html端显然是通过cookie存储比较方便,那么这个服务B,请求restful服务A的时候,用什么做认证呢?像我上面说的将token存在cookie里面是否靠谱?

learnshare

2015-04-23 15:27:33 +08:00

@gkiwi 再展开说说 token 的认证方式。

1. 所有要求登录后才能访问的 API 都必须携带有效的 token 来访问，否则就要求用户去登录；
2. 登录 API 可以 POST api_url/login {user, pswd}，然后返回 {token}，可以存到 cookie/localStorage 等位置。

token 的方式该如何控制安全性，可以自己多思考吧。

learnshare

2015-04-23 15:35:41 +08:00

@gkiwi 使用 RESTful 来写 API 之后，前端页面有两种方式来做：

1. 用另一个后端调用 API 来渲染；
2. 纯前端渲染，Ajax 等方式调用 API。

在某种程度上说，方式 1 不符合后端 API 化的目的（都已经写成 API 了，还要渲染页面干嘛）。不过后端渲染的方式也有其优势（性能高一些等）；
方式 2 就是将前端写成一个 WebApp，和写一个 Android/iOS App 类似的方式，通过 Ajax 等手段来访问 API。这种方式彻底分离了前后端，可以交给不同的人来做，相互之间都不用了解实现细节，只通过 API 文档沟通就可以了。

当然，也有一些前后端同时做页面渲染的技术，门槛高，没玩过。

gkiwi

2015-04-23 15:45:56 +08:00

@learnshare 确实如你所说的,似乎再用后端来渲染html不大合适,之前老想着认证这块,所以就痛哭了..

前后端渲染我用后端jinja2+前端vuejs做过一个web离线订单的处理,因为考虑纯离线的web操作,只能用前端框架做数据绑定和渲染,不过最后前端性能出了问题...

caixiexin

2015-04-23 15:51:04 +08:00

感觉像是在纠结是不是完全遵守RESTful设计网站，我刚接触的时候也有这种纠结 = =
用前端html模板渲染的方式还是后端渲染再吐给用户的方式？
看你的应用场景吧，我记得前端渲染一般都是单页型应用（Gmail，笔记网页版什么的），前端技术好的话可以做到很多酷炫的webapp，用上前端mvc框架还能做出兼容各种设备的响应试应用。但是有几个缺点：页面渲染慢，项目刚开始前端工作量比后端大，SEO支持不好什么的。传统后端渲染的优缺点就跟它相反了。业务复杂的站点肯定根据实际需求两种都会用到的。
个人觉得RESTful只是种http的资源设计风格，严格遵守的话，会束手束脚的。个人学习的话，多做些尝试或许能更明白一些。
我也半桶水，希望没说错：（

clino

2015-04-23 16:12:27 +08:00

我现在用uliweb+avalonjs写web应用的时候都是用这种方式,后端大部分只是提供api, javascript 的代码比后端的多不少

问题1,用avalonjs这种mvvm类型的刷新从api获取到的内容的时候只要管更新数据就可以了,用这类框架开发效率较高

问题2.2,对于我这里的情况,api接口和其他的接口没什么差别,一样可以用session来鉴别用户,当然不用这个用其他的机制也可以

这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/185717