Single record responses have pluralized key

[timohofmeijer]

The response for /users/123 is currently:

{
  "users": [
    {
      "key": "value"
    }
  ]
}

while Ember seems to be expecting:

{
  "user": {
      "key": "value"
  }
}

My setup (ember-cli 0.2.2 / ember 1.11.0 / ember-data 1.0.0-beta.16.1 / sails 0.11 / sails-generate-ember-blueprints 0.0.6) crapped out when requesting a single record saying:

Expected an object as `data` in a call to `push` for ...

[mphasize]

I recently changed it to the plural form according to a comment from @bmac here #9.

Apparently the RESTSerializer considers the singular form to be a bit of a legacy thing: https://github.com/emberjs/data/blob/master/packages/ember-data/lib/serializers/rest-serializer.js#L283-L287

And so far the plural form is working for me. (Still have to update to the very latest Ember Data).
I will take another look at this soon.

[bmac]

@timohofmeijer does the response for /users/123 contain id: 123?

[timohofmeijer]

@bmac nope, I’m trying to fetch data using username_slug,
so:

/users/bla

responds with:

{
  "users": [{
      "id": 123,
      "username": "bla",
    }]
}

You think this is causing my issue? You know a nice way to ‘normalize’ this back into id’s?
(I was just disabling slugs here and seem to get less errors)

[bmac]

Ah, Ember Data doesn't do so great when what it assumes to be the id (in this case bla) doesn't match the id on the record. emberjs/data#2558

However, I think the fact that it isn't throwing a more helpful error message then "Expected an object as data in a call to push for ..." feels like an ED bug to me.

[timohofmeijer]

That depends on how it was intended i think. If you want to support store.find(<any model property>) or just store.find(<primary key>). A clarifying error message would be welcome in case of the latter : )

For now I solved it by changing store.find('user', { username: params.user_slug }). This also resolved my primaryKey issue in sails-generate-ember-blueprints. The only thing not so nice is the lack of caching via the ED store.

[mphasize]

This looks like a good solution to me, or at least like a good work-around. Feel free to continue the discussion here, but I'm going to close this issue for now.