在Backbone中使用超媒体(REST)API

Question

在构建与RESTful(希望)API对话的Backbone.js SPA的过程中.我试图围绕资源设计API,使用超媒体将资源链接在一起.当我开始在Backbone中实现内容时,我开始意识到使用Backbone完成真正的超媒体可能不太适合.

主要问题是希望将路径预先声明的骨干路由器.使用良好的Hypermedia API,资源URI不应在客户端进行硬编码,以便灵活地添加新功能和(喘息)更改资源位置.

我正在尝试将客户端级页面资源与API级别的对象资源分离.有人尖叫,如果这是坚果.基本上,这意味着在我的骨干应用程序中定义到资源的路径(想想一个离散的页面),然后检索一个或多个API级资源.

这导致了一些有趣的问题:

1. 这甚至是个好主意吗？我是否应该尽力在我的应用程序中重用API级资源URI,使路由为1对1.

   • 我意识到页面和api对象只是同一资源的不同表示,但在大多数情况下,页面是多个资源的组合.或者我只是疯了:)

2. 在一系列导航过程中,页面刷新会发生什么.如果它们不相同,我如何知道API级资源的位置？

3. 在我看来,RESTful设计强调发现而不是事先了解事物.我是否正确地假设这个？这是代码下载的全部内容吗？如果我朝着正确的方向前进,有人可以指点我进一步阅读.

大多数资源都是只读的,因此只使用GET动词,但我确实有一些使用POST/PUT的场景(DELETE确实不在这个特定客户端的域中,除了可能在之前中止命令它被完全放置了.

*我只想说我绝不是一个REST大师.我还在学习中,所以请随时告诉我,我已完全离开了基地.没有感情会受到伤害.

编辑:

我一直在考虑与SPA相关的代码下载.还有一些选择:

1. 在动态加载的"API"资源或类似资源中定义资源URI(代码下载).这是一个例子:

   // this object downloaded along with the application code, on a refresh
   Framework.API.Resources = {
       Tasks: {
           uri: '/tasks',
           rel: 'self'
       },
       Users: {
           uri: '/users',
           rel: 'self'
       },
       // ... etc
   }
   
   // then in a collection
   
   var TaskCollection = Backbone.Collection.extend(
       uri: Framework.API.Resources.Tasks.uri
       // implementation details
   );
   

2. 使用"root"资源uri作为路线,在浏览资源时动态定义路线.我相信Backbone.Router.route可以实现这一点,但我不确定它是否可以在运行中进行.有没人试过这个？

Answer 1

虽然这就是 Roy Fielding 所描述的 REST 的意图，但我认为我们的框架（包括 Backbone.js）还没有实现这一点。在我看来，现在的 javascript 框架假设与远程资源存在一对一的映射。就我个人而言，我不会尝试在 Backbone.js 中实现超媒体