<commit_before>---
layout: page
title: Extensions
---

JSON API can be extended in several ways:

* The `supported-ext` and `ext` media type parameters can be used to negotiate
  support for extensions,
  [as discussed in the base specification](/format#extending).
  Official and custom extensions to the specification are discussed below.

* Meta information can be included in several places in a document,
  [as discussed in the base specification](/format/#document-structure-meta).

* A profile can be specified in the top-level `meta` object, as discussed below.

## Official Extensions <a href="#official-extensions" id="official-extensions" class="headerlink"></a>

JSON API currently supports the following official extensions:

* [Bulk extension](/extensions/bulk/) - provides support for performing multiple
  operations in a request, including adding and removing multiple resources.
  The Bulk extension is referenced with the extension name `bulk`.

* [JSON Patch extension](/extensions/jsonpatch/) - provides support for
  modification of resources with the HTTP PATCH method
  [[RFC5789](http://tools.ietf.org/html/rfc5789)] and the JSON Patch format
  [[RFC6902](http://tools.ietf.org/html/rfc6902)]. The JSON Patch extension is
  referenced with the extension name `ext=jsonpatch`.

## Custom Extensions <a href="#custom-extensions" id="custom-extensions" class="headerlink"></a>

The JSON API media type can be extended for your organization by writing your
own custom extension. This extension should also be specified using the `ext`
and `supported-ext` media type parameters.

It is strongly recommended that custom extensions be prefixed with a unique
identifier for your organization to avoid namespace collision. For example,
`my-org/embedded-resources`.

## Profiles <a href="#profiles" id="profiles" class="headerlink"></a>

JSON API can be extended with the profile link relation, defined in [RFC
6906](http://tools.ietf.org/html/rfc6906). See also [this blog post by Mark
Nottingham](http://www.mnot.net/blog/2012/04/17/profiles).

According to the RFC, profiles are:

```text
defined not to alter the semantics of the resource representation itself, but
to allow clients to learn about additional semantics (constraints, conventions,
extensions) that are associated with the resource representation, in addition
to those defined by the media type and possibly other mechanisms.
```

A profile link **SHOULD** be specified in the top-level `meta` object, keyed
by `profile`.
<commit_msg>Fix typo.<commit_after>---
layout: page
title: Extensions
---

JSON API can be extended in several ways:

* The `supported-ext` and `ext` media type parameters can be used to negotiate
  support for extensions,
  [as discussed in the base specification](/format#extending).
  Official and custom extensions to the specification are discussed below.

* Meta information can be included in several places in a document,
  [as discussed in the base specification](/format/#document-structure-meta).

* A profile can be specified in the top-level `meta` object, as discussed below.

## Official Extensions <a href="#official-extensions" id="official-extensions" class="headerlink"></a>

JSON API currently supports the following official extensions:

* [Bulk extension](/extensions/bulk/) - provides support for performing multiple
  operations in a request, including adding and removing multiple resources.
  The Bulk extension is referenced with the extension name `bulk`.

* [JSON Patch extension](/extensions/jsonpatch/) - provides support for
  modification of resources with the HTTP PATCH method
  [[RFC5789](http://tools.ietf.org/html/rfc5789)] and the JSON Patch format
  [[RFC6902](http://tools.ietf.org/html/rfc6902)]. The JSON Patch extension is
  referenced with the extension name `jsonpatch`.

## Custom Extensions <a href="#custom-extensions" id="custom-extensions" class="headerlink"></a>

The JSON API media type can be extended for your organization by writing your
own custom extension. This extension should also be specified using the `ext`
and `supported-ext` media type parameters.

It is strongly recommended that custom extensions be prefixed with a unique
identifier for your organization to avoid namespace collision. For example,
`my-org/embedded-resources`.

## Profiles <a href="#profiles" id="profiles" class="headerlink"></a>

JSON API can be extended with the profile link relation, defined in [RFC
6906](http://tools.ietf.org/html/rfc6906). See also [this blog post by Mark
Nottingham](http://www.mnot.net/blog/2012/04/17/profiles).

According to the RFC, profiles are:

```text
defined not to alter the semantics of the resource representation itself, but
to allow clients to learn about additional semantics (constraints, conventions,
extensions) that are associated with the resource representation, in addition
to those defined by the media type and possibly other mechanisms.
```

A profile link **SHOULD** be specified in the top-level `meta` object, keyed
by `profile`.

{'fraction_non_alphanumeric': 0.08913649025069638, 'fraction_numerical': 0.012733784321528054, 'mean_word_length': 4.935064935064935, 'pattern_counts': {'":': 0, '<': 15, '<?xml version=': 0, '>': 15, 'https://': 0, 'lorem ipsum': 0, 'www.': 2, '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': '7515030', 'n_tokens_mistral': 1351, 'n_tokens_neox': 1270, 'n_words': 597}