web-dev-qa-db-ja.com

Ember）で使用できるようにするためにRESTful JSONAPIに必要な規則

Ember モデルの紹介 ）には、次のように記載されています。

構成がない場合、Emberデータは、特定の規則に従っている限り、RESTful JSONAPIを介して提供されるレコードとその関係をロードおよび保存できます。

トークンベースのRESTfulJSON APIを使い始めましたが、これは一見厳密にはRESTfulではありません。いくつかの例：

  1. 認証はGET/api/[email protected]&password=passとして実装されます
  2. APIのほとんどは、失敗した場合でもステータス200（応答ヘッダー）を返します。返されるjsonには、APIが失敗したか合格したかを示す追加のフィールドsuccess（ブール値）とcode（int）が含まれています。
  3. URLは名詞（モデル）に基づいていません。たとえば、通常は/api/message/1/editのようなURLに対してPOSTであるはずの典型的なメッセージ編集操作は、GET /api/edit_message?id=1&text=newとして実装されます。

だから、誰かがこれらのcertain conventionsがドキュメントに記載されているものをリストできるかどうか疑問に思いました。これは、ember-dataを使用できるかどうかを理解するのに役立ちます。

ember.jsember-data
16
Code Poet

簡単に言うと、REST AP​​Iは実際にはRESTAPIではないため（HTTP動詞を使用せず、代わりに埋め込み）、EmberDataはおそらくRESTAPIには適していません。クエリ文字列の一部としてのアクション）。

なぜEmberデータはおそらくあなたには向いていないのか

あなたが説明しているようなAPIをサポートすることは、過去にはEmber Dataプロジェクトの目標であったかもしれませんが、最近では、Emberデータ開発者は次のように明示的に述べています。 Emberデータを非従来型のAPIで使用することは意図していません。たとえば、「ギャップを埋める」ことを目的としたBasicAdapterは、従来とは異なるEmberAPIでRESTデータを使用できるようにするために削除されました。

これが実際の見積もりとEmberjs.comのブログ投稿へのリンクです（読む価値があります）：

「EmberDataは、Ember.jsアプリが一貫性のある従来のAPIと通信するための最良のライブラリになることに焦点を当てます。」 （ http://emberjs.com/blog/2013/05/03/ember-data-progress-update.html ）

そのブログ投稿で推奨されているように、状況により適している可能性のある次のデータ永続性ライブラリを確認する必要があります。

https://github.com/endlessinc/ember-restless

https://github.com/ebryn/ember-model

最後に、Discourseの人々が行ったようにAJAXを使用していつでも自分でそれを行うことができます http://eviltrout.com/2013/03/23/ember-without-data.html

認証

私の知る限り、Ember Dataはアプリケーション認証を処理しません。これは、ここでの例で得られていると思います。認証システムについては、Ember.SimpleAuth（ https://github.com/simplabs/ember-simple-auth ）のようなものを見ることができます。これは高度に構成可能であり、認証メカニズムで機能するはずです（ただし間違いなくカスタムオーセンティケーターを作成する必要があります）。

カスタムオーセンティケーターの作成は非常に簡単です。

Emberデータが実際に期待しているもの

まだご覧になっていない場合は、このページをお読みになることをお勧めします： http://emberjs.com/guides/models/the-rest-adapter/

Ember Dataは、意図を伝えるためにHTTP動詞を使用します。したがって、モデルの1つでcreateRecordを呼び出してストアを保存すると、EmberDataはHTTPPOSTをRESTAPIに発行します。レコードを取得しようとすると、EmberはGETリクエストを発行します。レコードを削除しようとすると、EmberはDELETEリクエスト（など）を発行します。

次のような3つのモデルがあるとします。

_module.exports = App.ShoppingCart = DS.Model.extend({
    user: DS.belongsTo('user'), 
    items: DS.hasMany('item', {async:true}),
    name: attr('string'),
    enabled: attr('boolean')
});

module.exports = App.Item = DS.Model.extend({
    name: attr('string')
});

module.exports = App.User = DS.Model.extend({
   firstName: attr('string')
   lastName: attr('string')
});
_

this.store.find('shoppingCart', 1) Emberを使用してレコードを読み込もうとすると、モデル名の複数形（この場合は_GET /shoppingCarts/1_）に対してGET要求が行われます。 Emberには、Wordの複数形を決定するための一連のルールが組み込まれているため、たとえば、searchの複数形はsearchesであり、searchsではないことがわかります。 GETリクエストが行われると、RESTAPIは次のJSONを返す必要があります。

_{
  "shoppingCart": {
      "id": 1,
      "name": "Bobs Shopping Cart",
      "user": 1, //this field links to the user with an id of 1
      "enabled": true,
      "items": [
        1,
        2
      ] 
    }
}
_

this.store.find('shoppingCart')を実行している場合、Ember Dataは_GET /shoppingCarts_を発行し、複数形のモデル名でキー設定されたショッピングカートオブジェクトの配列を返します。たとえば、次のようになります。

_{
  "shoppingCarts": [
     {
       "id": 1, //not specified in the model but must be sent by the REST API
       "name": "Bob's Shopping Cart",
       "user": 1, //this field links to the user with an id of 1
       "enabled": true,
       "items": [
         1,
         2
       ] 
     },
     {
       "id": 2, 
       "name": "John's Shopping Cart",
       "user": 2, //this field links to the user with an id of 2
       "enabled": false,
       "items": [
         3,  // these are ids for the item models
         4
       ] 
     }
  ]
}
_

サーバーからレコードを返すときは、返されるレコードを一意に識別するidフィールドを含める必要があることに注意してください。 idフィールドは、モデル自体では指定されていません。新しいレコードを作成してサーバーにデータを送信する場合、idフィールドは含めません（サーバー側で決定されるため）が、REST AP​​Iは、IDが何であるかを返す必要があります。応答。

上記の例では、Emberデータのストアにユーザー "1"がキャッシュされている場合、その情報のみが使用されます。それ以外の場合は、_GET /users/1_に対して別のGETリクエストが行われ、ユーザーの情報が取得されます。 1.（複数のGET要求を回避したい場合は、レコードをサイドロードすることで、これをより効率的にすることができます）。

要約すると、慣例では、HTTP動詞を使用して、実行するアクションを伝えます。Ember Dataがリクエストを送信するURLは、クエリしているモデル名の複数形に基づいています。

大きな警告

私が上で書いたことのほとんどは、あまりカスタマイズせずに「箱から出して」Emberデータを使用したいという仮定に基づいています。一般的に言って、Ember AP​​Iを制御でき、REST Dataの意見に準拠するように調整できる場合、EmberDataは最も扱いやすいと思います。 JSONベースのRESTAPIが機能するはずです。 Ember Dataのデフォルトの動作を変更することは可能ですが、APIに合わせてEmber Dataを曲げようとした経験があまりないため、他の誰かからの入力が必要になる場合があります。これを行おうとしました。

48
Sarus