Series: Introduction to Ember Data 2.0

RESTAdapter vs JSONAPIAdapter vs ActiveModelAdapter

Published on Jan 29, 2016

The past three videos have covered the RESTAdapter in depth, but there are several other commonly used Adapters.

In this video we look at how the JSONAPIAdapter (included in Ember Data) and the ActiveModelAdapter (previously in Ember Data, now in an addon) differ from the RESTAdapter.


Links

Code

The code for this screencast is entirely in the JSONAPIAdapter and the ActiveModelAdapter

Transcript

In the last three episodes, we’ve gone over every customizable method in the RESTAdapter that comes with Ember data. However, that’s not the only adapter that comes with Ember data. There’s also the JSONAPIAdapter, and there used to be the ActiveModelAdapter, although that is now in an add-on instead of as part of Ember data. So we’ll go over those and discover the differences between the RESTAdapter and these other two commonly used adapters.

To start us off, here’s the app that we’ve been using to show the routes that are given by the various methods for an adapter. Here we have the RESTAdapter, and we’re using the model taco-taco, and we’ll see that it camelCases it and pluralizes it. And then for these sets of methods, we have POST, PUT, DELETE, and then four GETs.

If we change this from the RESTAdapter to the JSONAPIAdapter, then we’ll notice that it does kebab-case instead of camelCase, and it’s changed this PUT to a PATCH. Let’s go ahead and see how it does that.

So here we have the JSONAPIAdapter in Ember data. We’ll see that it extends the RESTAdapter, and then it makes it so unless you specify it otherwise, it’ll use the JSONAPI Serializer. Then it messes with ajaxOptions. We didn’t go over these last time because it’s a private method and we went over all the public methods. But what this does, first it calls the default ajaxOptions that we have in the RESTAdapter, and then it changes the content type to something that JSONAPI expects. And then it adds a request header before sending.

This construct may look a little confusing, but it’s basically taking the beforeSend method, setting it somewhere else, adding something to the new one, and then calling the old version of beforeSend. So it’s like calling super but on a method instead of a class. And then it just returns the hash.

So coalesceFindRequests, this is the same as in RESTAdapter. It’s just put in there I guess for emphasis. And then findMany, the difference here is that instead of... here we’ll see the findMany... it puts the ids as an array in the data hash. And here it’s in the data hash but also under filter, and then the ids aren’t in an array. They’re in a string joined by a comma. So once again just little things that JSONAPI expects to be different.

Then pathForType is something that... this is the thing that we saw earlier. It dasherizes it instead of having it camelCase. And then it pluralizes it, just like it did in the RESTAdapter.

Then finally updateRecord is largely the same thing as the updateRecord in RESTAdapter, but it’s PATCH instead of PUT, and as you can see by this comment, this is unfortunately still the best way to overwrite an HTTP verb, even though it’s repeating these five lines.

And those are all the changes that we need to make to the adapter in order to have JSONAPI. Of course when we get to serializer, there’s going to be a lot more changes than that, so get ready.

Alright, so that was JSONAPIAdapter. Let’s look at the ActiveModelAdapter. And we’ve imported this from the add-ons since in Ember data 2.0 it’s been moved to an add-on.

Here we see that it has underscore or snake case instead of dasherized or camelCase, and we’re back to having a PUT instead of a PATCH.

The ActiveModelAdapter is even simpler of a change than the JSONAPIAdapter. Of course you have your defaultSerializer, which is active-model, and that’s where most of the changes are going to be happening. Ones that happen in the adapter itself are pathForType, which it decamelizes it, and then it underscores it, and then it pluralizes it. So that’s how we get this.

And then when you’re handling the response, it checks isInvalid first, and then it handles those errors differently.

And so that wraps up our series on Ember data adapters. In the next set of episodes, we’ll be going over Ember data serializers, and how you can use and customize those, as well as find our way around the default ones that are available. Alright, I’ll see you then.

Introduction to Ember Data 2.0

Subscribe to our mailing list