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

Question

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

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

我在玩解耦客户端级的想法页面资源 来自 API 级别 对象资源 .如果这很疯狂，有人会尖叫。基本上，这意味着在我的主干应用程序中定义资源的路由(想想一个离散页面)，然后将检索一个或多个 API 级资源。

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

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

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

在一系列导航的中间页面刷新会发生什么。如果 API 级别资源不相同，我如何知道它们的位置？

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

大多数资源都是只读的，所以只使用 GET 动词，但我确实有一些使用 POST/PUT 的场景(DELETE 确实不在这个特定客户端的域中，除了可能在之前中止订单它已完全放置)。

*我只想说，我绝不是 REST 大师。我仍在学习中，所以请随时告诉我我完全偏离了基地。任何感情都不会受到伤害。

编辑:

我一直在思考与 SPA 相关的代码下载。还有几个选项:

在动态加载(代码下载)的“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
);

在您浏览资源时动态定义您的路线，使用“根”资源 uri 作为您的路线。我相信 Backbone.Router.route 可以做到这一点，但我不确定是否可以即时完成。有没有人试过这个？

Answer 1

回复 #3

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

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

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

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