5

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

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

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

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

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

    • 我意识到一个页面和一个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 可以做到这一点，但我不确定是否可以即时执行。有没有人试过这个？

4

2 回答 2

1

回复 #3

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

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

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

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

于 2012-07-25T15:05:39.863 回答
0

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

于 2012-07-25T13:35:19.360 回答