Question

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

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

我正在尝试将客户端级页面资源与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
);

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

Answer 1

Re＃3

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

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

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

我认为你的SPA和页面没有理由需要资源为1-1。 REST的一个原则是它是Client - ＆gt;服务器因此它们可以以不同的方式发展。如果你获得了将它们设为1-1的设计优势，那么这就是你的选择。

Answer 2

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

在Backbone中使用超媒体（REST）API

2 个答案: