Ember Data and REST response

#1

Hi,

I am kind of new to ember and I started to transition an existing web application to SPA. In the long run I would like to consider the browser just as another client consuming a REST api (among other clients like mobile apps…). The REST api is very similar to what is described in this great talk: https://stormpath.com/blog/designing-rest-json-apis/ So, it is not actually that similar to what is described as a JSON API.

For now I have come across a few issues with using the ember data RESTAdapter:

If I have a resource like: http://host.com/books the Adapter expects my response to be:

{   
  "books": [
    {
      "id": 1
    } 
  ] 
}

This is kind of redundant to me as I already know that I request for a list of books via the resource. So, it would be sufficient to just return the list of books:

[
  {
    "id": 1
  }
]

The above mentioned talk has a very neat convention about resource expansion via query parameters. However, I am just mentioning that, since I noticed that the JSON api relies on these conventions for that matter.

#2

In that case you should probably adjust the way the adapter works in a subclass of the adapter. I think the way ember-data works is very standard, however. One usually has a root element, otherwise when you want to do sideloading, things would become… complicated.

#3

I agree- the “standard” api conventions used in ember data don’t seem very standard. If you have control over your API, it’s a little less painful to roll with it. Some other things worth noting:

Most of the documentation examples show data being side-loaded (which is why everything needs root elements), but apis that don’t sideload will still work out the box as long as you include an array of ids for it to look up on additional requests.

The root elements are still subject to the pluralizer.

If your api is served from another domain, every endpoint has to be able to respond an OPTIONS request for its CORS headers.

Your PUT and POST requests have to return complete objects.

People will say that the REST adapter works with “standard” api architecture, but in my experience, that means Rails architecture. The conventions aren’t awful or illogical, but they are special.

#4

Oh, and the endpoints also don’t nest, which is bizarre, but I think that can be overridden on a per-endpoint basis.

#5

When thinking about it, it actually makes sense to not have an array returned as the JSON root element. That would prevent adding any clean implementation of pagination. However, it would be great if these ember-data conventions would be a little more configurable. For instance there are many APIs out there that don’t use the actual names of the resources, but use a more generic identifier like ‘items’.

Btw, nesting is one of the issues I encountered as well. However, it actually made sense to refactor the endpoint to not nest. Luckily I was able to make that decision.

#6

You can configure using adapters and serializers. Also, the conventions are based in large part on htpp://jsonapi.org

#7

@ulisesrmzroche speaking of configuring the adapter, would you mind looking at my “server-side paginated” findMany and helping me work out what’s wrong with it? It’s a bit beyond me, I feel.

#8

Yeah, for sure. If I can figure it out, I’ll post something up. How you doing, bro?!

#9

Oh nevermind. I built a solution myself.

I’m going okay… my project’s slowly coming together… there are a lot of very manual things so far. :slight_smile: I need more clients. :slight_smile:

#10

The basic JSONSerialzier doesn’t do sideloading so it doesn’t expect to have things nested under a key. If you don’t expect to need sideloading for a particular model/your whole app you can just configure it to use the JSONSerializer.