5

RESTful (できれば) API と通信する Backbone.js SPA を構築中。ハイパーメディアを使用してリソースをリンクし、リソースを中心に API を設計しようとしました。Backbone での実装を開始すると、Backbone で真のハイパーメディアを実現するのは適切ではない可能性があることに気付き始めています。

主な問題は、パスを事前に宣言したいバックボーン ルーターです。優れたハイパーメディア API では、リソース URI をクライアントにハードコーディングしないでください。これにより、新しい機能を追加したり、リソースの場所を (あえぎ) 変更したりする際の柔軟性が確保されます。

クライアント レベルのPage Resourcesを API レベルのObject Resourcesから分離するというアイデアで遊んでいます。これがおかしいと誰かが叫ぶ。基本的に、これはバックボーン アプリ (個別のページを考えてください) 内のリソースへのルートを定義することを意味し、1 つ以上の API レベルのリソースを取得します。

これは、いくつかの興味深い質問につながります。

  1. これも良い考えですか？ルートが 1 対 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

コード オン デマンドの実際の例を見つけるのは難しく、そうする理由はまだ見つかりません。

2か所で発見を考えています。1) 後でコーディングできる事前の発見。たとえば、すべてのブラウザーは、HTML を処理することを認識しており、メディア タイプに合わせて事前に設計できます。2) ランタイム検出。ブラウザは何を処理する必要があるかを認識していますが、それらのメッセージの内容は認識していません。ハイパーメディアを介して移動するためのメカニズムがありますが、実行時にその実行を検出します。

私が取り組んでいるアプリで。デザインタイム ディスカバリを使用して、REST API のドキュメントを調べました。この API は、考えられるすべてのリンク関係、メディア タイプ、およびハイパーメディアの詳細を示します。すべての可能なハイパーメディアに基づいてクライアントをコーディングしました。実行時に、ハイパーメディアが存在するかどうかに基づいて、それらが利用可能かどうかを確認しました。

SPA とページがリソースと 1 対 1 である必要がある理由がわかりません。REST の原則の 1 つは、それがクライアント --> サーバーであるため、異なる方法で進化できるということです。それらを1対1にすることで設計上の利点が得られる場合は、それがあなたの選択です.

于 2012-07-25T15:05:39.863 に答える
0

Roy Fielding が説明したように、それが REST の意図でしたが、Backbone.js を含むフレームワークはまだそこに達していないと思います。最近の JavaScript フレームワークは、リモート リソースとの 1 対 1 のマッピングがあると想定しているように思えます。個人的には、Backbone.js に Hypermedia を実装しようとは思いません。

于 2012-07-25T13:35:19.360 に答える