用于backbone.js 和 co 的宁静后端框架
what's left to do for a backend framework in order to provide a restful service to a frontend application based on backbone.js or other full MVC frontend framework?
I can think of
- data
- storage
- versioning
- validation
- authorization
- (refential) integrity
- user authentication
- event notification to client
what else?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
一些额外的事情（尽管任何事情都可能被视为您在问题中已经提到的事情的一部分）：
充当中介
只要我们对 Ajax 有域限制，就有必要提供代理来启用混搭。然而，即使我们解决了这个问题，中介机构仍然会遇到其他情况。以 Twitter 的流 API 为例。 Twitter 只允许每个 API 密钥一个流，因此您的后端应用程序必须是消费者，然后将搜索结果发送给客户端。
搜索
带宽和客户端处理能力都限制了在客户端上执行搜索的程度。
作业
后台或批处理作业处理通常最好在服务器上完成。一个好的 RESTful 实践是
POST到/jobs，获得一个202 Accepted，其中Content-Location标头指向到正在运行的作业。该作业的后续操作会返回状态，如果完成，还会返回结果的链接。A few additional things (though any could probably be considered parts of things you've already mentioned in the question):
Acting as an intermediary
As long as we have domain restrictions on Ajax, it will be necessary to offer a proxy to enable mashups. Even once we fix that problem, though, there are other cases for an intermediary. Take, for example, Twitter's streaming API. Twitter only allows one stream per API key, so your backend app will have to be the consumer that then sends search results to the clients.
Search
Bandwidth and client processing capabilities both limit the degree to which search can be done on the client.
Jobs
Background or batch job processing is often best done on the server. A good RESTful practice is to
POSTto/jobs, get a202 Acceptedwith aContent-Locationheader pointing to the running job. Subsequents to that job return a status and, if it's complete, a link to the results.迁移到前端驱动的架构时需要考虑的非常重要的一件事是，在许多情况下，您需要为搜索引擎生成内容。
因此，理想情况下，您的架构能够在服务器端路由和评估模板/视图。我认为目前非常缺乏在客户端和服务器端使用相同逻辑的能力。
看起来您几乎已经列出了所有后端任务，但是这个新架构确实为您需要如何执行这些操作提供了更多细节，因此它不一定像列表看起来那么容易。
The one thing that is very important to consider when moving to a front end powered architecture, is that in many cases you will need to generate content for search engines.
So ideally your architecture is capable of routing and evaluating templates / views on the server side. I think this ability to use the same logic on client and server side is something that is very lacking at the moment.
It looks like you pretty much have the backend tasks all listed there, but this new architecture does bring further detail into how you need to do these things, so it's not necessarily as easy as it the list makes it seem.