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

Question

在构建与 RESTful（希望如此）API 对话的 Backbone.js SPA 的过程中。我尝试围绕资源设计 API，使用超媒体将资源链接在一起。当我开始在 Backbone 中实现一些东西时，我开始意识到使用 Backbone 实现真正的超媒体可能并不合适。

主要问题是骨干路由器希望预先声明其路径。使用良好的超媒体 API，资源 URI 不应在客户端中硬编码，以便灵活地添加新功能和 (gasp) 更改资源位置。

我正在尝试将客户端级页面资源与 API 级对象资源分离。如果这很疯狂，有人会尖叫。基本上，这意味着在我的主干应用程序中定义到资源的路由（想象一个离散页面），然后检索一个或多个 API 级别的资源。

这引出了一些有趣的问题：

1. 这是个好主意吗？我是否应该尽我所能在我的应用程序中重复使用 API 级别的资源 URI，以便路由是一对一的。

   • 我意识到 page 和 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. 在您浏览资源时动态定义您的路线，使用“根”资源 uri 作为您的路线。我相信 Backbone.Router.route 可以做到这一点，但我不确定是否可以即时执行。有人试过吗？

Answer 1

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

Answer 2

关于#3

现实世界中的按需代码示例很难找到，我还没有找到这样做的理由。

我想到了两个地方的发现。 1) 预先发现，然后您可以对其进行编码。因此，例如，每个浏览器都知道他们将处理 HTML，并且可以预先设计媒体类型。 2) 运行时发现，虽然浏览器知道他们需要处理什么，但他们不知道这些消息中有什么。尽管超媒体已经完成，但它们具有移动机制，但会在运行时发现它的执行。

在我正在开发的应用中。我们使用设计时发现来查看 REST API 的文档。该 API 详细说明了所有可能的链接关系、媒体类型和超媒体。我们根据所有可能的超媒体对客户端进行了编码。在运行时，我们根据超媒体是否存在来检查它们是否可用。

我看不出为什么您的 SPA 和页面需要与资源保持 1-1 的关系。 REST 的原则之一是它是客户端 --> 服务器，因此它们可以以不同的方式发展。如果您通过使它们 1-1 获得设计优势，那么这就是您的选择。