Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

optional root for RESTAdapter #771

Closed
necronet opened this Issue · 18 comments
@necronet

Hello I had this problem when implementing the RESTAdapter, since I do not send the type as a parameter of my services calls as ember-data currently does:

{"person":{"atribute1":"jjj","atribute2":"jjj"}}

Is more like

{"atribute1":"jjj","atribute2":"jjj"}

I did not find any easy way to override this behaviour so I had to reimplement the same code of the Adapter createRecord but without the root. I am not a mastering in front-end so might be a good idea to put a jsonWithRoot or some similar property to RESTAdaper to easly handle this case.

Here is the Stackoverflow

http://stackoverflow.com/questions/15126081/ember-data-customs-serializing

@darthdeus
Collaborator

I think this might cause a lot of issues in other places. For example how would you determine sideloading when everything is top level?

@necronet

I though that the whole ember can play nice with other API, and as far as I know REST never saids anything about root your object with the resources is pointing to, so Sideloading is json specific? how would you determing it if you're endpoint does not comply with this rootish structure?

@hashg

My JSON is in this format

{
  "total_pages": 1, 
  "objects": [
    {
      "updated": null, 
      "desc": "Team USA", 
      "id": "1", 
      "isActive": true, 
      "name": "USA"
    }, 
    {
      "updated": null, 
      "desc": "Team EMEA", 
      "id": "2", 
      "isActive": true, 
      "name": "EMEA"
    }, 
    {
      "updated": null, 
      "desc": "Team India", 
      "id": "3", 
      "isActive": true, 
      "name": "India"
    }
  ], 
  "num_results": 3, 
  "page": 1
}

How do I inform RestAdapter to pick up always data.objects ?

@SquireLabs

I'm using flask restless and it also expects the POST/PUT data not to have a root identifier. Regarding sideloading, could we not assume that if there is no root key then sideloading happens within the actual payload. eg

{
    "person": {
        "name": "Foo",
        "surname": "Bar"
    },
    "address": {
        "street": "rest ave"
    }
}

to

{
    "name": "Foo",
    "address": {
        "street": "rest ave"
    }
}

I'd say if the API expects no root, it should be clever enough to figure out the relationships from the json object.

@igorT
Owner

In most cases you really should have a rooted JSON, as that gives you much more flexibility as you develop your API. However, I do agree that the behaviour should be easier to override. I am adding a customUrl hook and after that I can refactor the code to accept a custom root as well. For loading you can override https://github.com/emberjs/data/blob/master/packages/ember-data/lib/serializers/json_serializer.js#L186
while for PUT/POST its a bit more annoying.

@SquireLabs

According to the docs "We also understand that there exist many web service APIs in the world, many of them crazy, inconsistent, and out of your control. Ember Data is designed to be configurable to work with whatever persistence layer you want, from the ordinary to the exotic."

When I read this for the first time I assumed ember would be able to deal with different ways of sending data to an api. Afterall, ember doesn't really care about the actual 'presistance layer' as much as it cares about the api endpoints and how to interact with them. While for me its relatively easy to change my endpoints since i'm using it for a sideline project, the barrier to entry with ember might be a bit higher when developers realize its hard to change the format of the json payload from ember.

However, I agree with Igor that it makes sense to define the root in the JSON. In my experience I just haven't found it to be as prevalent.

@igorT
Owner

Yup, we are not doing that great of a job for easily customizing the rest-adapter, though my hope is that most frameworks there will be specific adapters(like the django adapters). If you have a truly crazy API, the basic adapter is a better bet. Simple things like this should be easily overridable though.

@ghempton
Collaborator

Related to #619

@wagenet
Owner

@tomdale and @wycats are working on adapter improvements that will make it easier to hook into these places. For now, there are still methods you can override in the adapter, e.g. didFindRecord, that can address this case.

@wagenet wagenet closed this
@gnuwilliam

Hello guys! Any progress on that?

@wycats
Owner

You can do something like this:

App.ApplicationSerializer = DS.RESTSerializer.extend({
  serializeIntoHash: function(hash, type, record, options) {
    Ember.merge(hash, this.serialize(record, options));
  }
});
@gnuwilliam

Wow! That was quick! :-)

Thanks @wycats, I appreciate.

@jayphelps

@wycats If you guys are keeping examples of FAQ, I think your solution deserves a spot. It's obvious in hindsight but at first I thought I'd have to change the convention serialize() expects by passing along the referenced hash object.

Side note: I'm not sure why serializeIntoHash is actually passed a clean object by reference to use instead of just allowing it to return any object it wants though. There may have been a reason, but can't tell from the source. I'm happy to PR if interested, but it would be breaking change unless it supports both. i.e. If serializeIntoHash returns an object it is used instead of the passed hash object.

@elucid

I was surprised by this as well.

@bmac
Collaborator

@jayphelps That sounds like a great idea. I've seen several developers on irc and in person miss the fact that serializeIntoHash can be used to transform data because it doesn't return an object.

@marbemac

@wycats serializeIntoHash doesn't seem to get called for me, so I had to override extractSingle and extractArray.

@hashg here is how I did it with a key called "data". Would work for your "objects" key as well with some simple tweaks.

https://gist.github.com/marbemac/06c5040e4d71694f07b3

@hashg

@marbemac thank you

@Emerson

@marbemac - I also had to use your method - worked great, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.