<commit_before>In Ember Data, the Adapter determines how data is persisted to a
backend data store, such as the URL format and headers for a REST API.
(The format of the data itself is determined by the
[serializer](../customizing-serializers/).)
Ember Data's default Adapter has some built-in
assumptions of how a [REST API should look](http://jsonapi.org/). If
your backend conventions differ from these assumptions Ember Data
makes it easy to change its functionality by swapping out or extending
the default Adapter.

Some reasons for customizing an Adapter include using
`underscores_case` in your urls, using a medium other than REST to
communicate with your backend API or even using a
[local storage backend](https://github.com/locks/ember-localstorage-adapter).

Extending Adapters is a natural process in Ember Data. Ember takes the
position that you should extend an adapter to add different
functionality. This results in code that is
more testable, easier to understand and reduces bloat for people who
may want to subclass your adapter.

If your backend has some consistent rules you can define an
`adapter:application`. The `adapter:application` will get priority over
the default Adapter, however it will still be superseded by model
specific Adapters.

```app/adapters/application.js
import DS from 'ember-data';

export default DS.JSONAPIAdapter.extend({
  // Application specific overrides go here
});
```

If you have one model that has exceptional rules for communicating
with its backend than the others you can create a Model specific
Adapter by running the command `ember generate adapter adapter-name`.
For example, running `ember generate adapter post` will create the
following file:

```app/adapters/post.js
import DS from 'ember-data';

export default DS.JSONAPIAdapter.extend({
  namespace: 'api/v1'
});
```

Ember Data comes with several built-in adapters.
Feel free to use these adapters as a starting point for creating your own custom adapter.

- [DS.Adapter](https://www.emberjs.com/api/ember-data/2.16/classes/DS.Adapter) is the basic adapter
with no functionality. It is generally a good starting point if you
want to create an adapter that is radically different from the other
Ember adapters.

- [DS.JSONAPIAdapter](https://www.emberjs.com/api/ember-data/2.16/classes/DS.JSONAPIAdapter)
The `JSONAPIAdapter` is the default adapter and follows JSON API
conventions to communicate with an HTTP server by transmitting JSON
via XHR.

- [DS.RESTAdapter](https://www.emberjs.com/api/ember-data/2.16/classes/DS.RESTAdapter)
The `RESTAdapter` allows your store to communicate with an HTTP server
by transmitting JSON via XHR. Before Ember Data 2.0 this adapter was the default.


## Customizing the JSONAPIAdapter

The
[DS.JSONAPIAdapter](https://www.emberjs.com/api/ember-data/2.16/classes/DS.JSONAPIAdapter)
has a handful of hooks that are commonly used to extend it to work
with non-standard backends.

### URL Conventions

The `JSONAPIAdapter` is smart enough to determine the URLs it
communicates with based on the name of the model. For example, if you
ask for a `Post` by ID:

```js
store.findRecord('post', 1).then(function(post) {<commit_msg>update urls to latest release<commit_after>In Ember Data, the Adapter determines how data is persisted to a
backend data store, such as the URL format and headers for a REST API.
(The format of the data itself is determined by the
[serializer](../customizing-serializers/).)
Ember Data's default Adapter has some built-in
assumptions of how a [REST API should look](http://jsonapi.org/). If
your backend conventions differ from these assumptions Ember Data
makes it easy to change its functionality by swapping out or extending
the default Adapter.

Some reasons for customizing an Adapter include using
`underscores_case` in your urls, using a medium other than REST to
communicate with your backend API or even using a
[local storage backend](https://github.com/locks/ember-localstorage-adapter).

Extending Adapters is a natural process in Ember Data. Ember takes the
position that you should extend an adapter to add different
functionality. This results in code that is
more testable, easier to understand and reduces bloat for people who
may want to subclass your adapter.

If your backend has some consistent rules you can define an
`adapter:application`. The `adapter:application` will get priority over
the default Adapter, however it will still be superseded by model
specific Adapters.

```app/adapters/application.js
import DS from 'ember-data';

export default DS.JSONAPIAdapter.extend({
  // Application specific overrides go here
});
```

If you have one model that has exceptional rules for communicating
with its backend than the others you can create a Model specific
Adapter by running the command `ember generate adapter adapter-name`.
For example, running `ember generate adapter post` will create the
following file:

```app/adapters/post.js
import DS from 'ember-data';

export default DS.JSONAPIAdapter.extend({
  namespace: 'api/v1'
});
```

Ember Data comes with several built-in adapters.
Feel free to use these adapters as a starting point for creating your own custom adapter.

- [DS.Adapter](https://www.emberjs.com/api/ember-data/release/classes/DS.Adapter) is the basic adapter
with no functionality. It is generally a good starting point if you
want to create an adapter that is radically different from the other
Ember adapters.

- [DS.JSONAPIAdapter](https://www.emberjs.com/api/ember-data/release/classes/DS.JSONAPIAdapter)
The `JSONAPIAdapter` is the default adapter and follows JSON API
conventions to communicate with an HTTP server by transmitting JSON
via XHR.

- [DS.RESTAdapter](https://www.emberjs.com/api/ember-data/release/classes/DS.RESTAdapter)
The `RESTAdapter` allows your store to communicate with an HTTP server
by transmitting JSON via XHR. Before Ember Data 2.0 this adapter was the default.


## Customizing the JSONAPIAdapter

The
[DS.JSONAPIAdapter](https://www.emberjs.com/api/ember-data/release/classes/DS.JSONAPIAdapter)
has a handful of hooks that are commonly used to extend it to work
with non-standard backends.

### URL Conventions

The `JSONAPIAdapter` is smart enough to determine the URLs it
communicates with based on the name of the model. For example, if you
ask for a `Post` by ID:

```js
store.findRecord('post', 1).then(function(post) {
{'fraction_non_alphanumeric': 0.07133917396745933, 'fraction_numerical': 0.0031289111389236545, 'mean_word_length': 4.743935309973046, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 10, 'lorem ipsum': 0, 'www.': 8, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '2349436', 'n_tokens_mistral': 1756, 'n_tokens_neox': 1675, 'n_words': 826}