<commit_before>---
title: JSON API Updating
---

# JSON API Updating

See also: 

- [Reading](/)
- [History](/history)

## URLs

Update URLs are determined [the same way][1] as `GET` URLs. When using the
ID-based approach, URLs are conventionally formed. When using the
URL-based approach, every document specifies the URLs for its related
documents, which can be used to fetch **and** update.

[1]: /

## Creating a Document

A JSON API document is *created* by making a `POST` request to the URL
that represents a collection of documents that the new document should
belong to.

In general, this is a collection scoped to the **type** of document.

The request **MUST** contain a `Content-Type` header whose value is
`application/json`. It **MUST** also include `application/json` as the
only or highest quality factor.

Its root key **MUST** be the same as the root key provided in the
server's response to `GET` request for the collection.

For example, assuming the following request for the collection of
photos:

```text
GET /photos

HTTP/1.1 200 OK
Content-Type: application/json

{
  "posts": [{
    "id": 1,
    "title": "Mustaches on a Stick",
    "src": "http://example.com/images/mustaches.png"
  }]
}
```

You would create a new photo by `POST`ing to the same URL:

```text
POST /photos
Content-Type: application/json
Accept: application/json

{
  "photos": {
    "title": "<NAME>",
    "src": "http://example.com/images/productivity.png"
  }
}<commit_msg>fix copypasta<commit_after>---
title: JSON API Updating
---

# JSON API Updating

See also: 

- [Reading](/)
- [History](/history)

## URLs

Update URLs are determined [the same way][1] as `GET` URLs. When using the
ID-based approach, URLs are conventionally formed. When using the
URL-based approach, every document specifies the URLs for its related
documents, which can be used to fetch **and** update.

[1]: /

## Creating a Document

A JSON API document is *created* by making a `POST` request to the URL
that represents a collection of documents that the new document should
belong to.

In general, this is a collection scoped to the **type** of document.

The request **MUST** contain a `Content-Type` header whose value is
`application/json`. It **MUST** also include `application/json` as the
only or highest quality factor.

Its root key **MUST** be the same as the root key provided in the
server's response to `GET` request for the collection.

For example, assuming the following request for the collection of
photos:

```text
GET /photos

HTTP/1.1 200 OK
Content-Type: application/json

{
  "photos": [{
    "id": 1,
    "title": "Mustaches on a Stick",
    "src": "http://example.com/images/mustaches.png"
  }]
}
```

You would create a new photo by `POST`ing to the same URL:

```text
POST /photos
Content-Type: application/json
Accept: application/json

{
  "photos": {
    "title": "<NAME>",
    "src": "http://example.com/images/productivity.png"
  }
}
{'fraction_non_alphanumeric': 0.11696701802108127, 'fraction_numerical': 0.005440326419585175, 'mean_word_length': 3.854785478547855, 'pattern_counts': {'":': 14, '<': 5, '<?xml version=': 0, '>': 5, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, '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': '5238075', 'n_tokens_mistral': 927, 'n_tokens_neox': 872, 'n_words': 391}