Справочник «Стандарты и сертификаты» · тема 3
Глава 4
Стандарты интернета:
HTTP, JSON, дата и текст
Браузер, сервер и мобильное приложение разных производителей работают вместе, потому что следуют одним документам. В главе разобраны стандарты, на которых держится обмен данными: HTTP, JSON, запись даты и времени, кодирование текста.
- Документы
- RFC 9110 · RFC 8259 · RFC 3339 · RFC 9457 · ISO 8601 · ISO/IEC 10646
- Уровень
- Базовый
- Где встречается
- Любой сайт, API, журнал сервера
- Зачем это знать
- Чтобы читать журналы и проектировать API по общим правилам
§1Что такое RFC
RFC — серия документов, в которой публикуются стандарты интернета. Выпускает их Инженерный совет Интернета (IETF). Тексты бесплатны и лежат на сайте rfc-editor.org.
У каждого RFC постоянный номер. Текст опубликованного документа не меняют: новая редакция выходит под новым номером, а в шапке старого появляется строка «Obsoleted by».

| Документ | Что описывает | Год |
|---|---|---|
| RFC 9110 | смысл методов, кодов ответа и заголовков HTTP | 2022 |
| RFC 8259 | формат JSON | 2017 |
| RFC 3339 | запись даты и времени в интернете, профиль ISO 8601 | 2002 |
| RFC 9457 | формат описания ошибки в HTTP API (Problem Details) | 2023 |
| RFC 8446 | протокол TLS версии 1.3 | 2018 |
§2Методы HTTP
RFC 9110 делит методы по двум свойствам. Безопасный метод не меняет состояние ресурса. Идемпотентный метод при повторе даёт то же состояние, что и после первого вызова.
| Метод | Назначение | Безопасный | Идемпотентный |
|---|---|---|---|
| GET | получить ресурс | да | да |
| HEAD | получить только заголовки | да | да |
| OPTIONS | узнать доступные методы | да | да |
| PUT | заменить ресурс целиком | нет | да |
| DELETE | удалить ресурс | нет | да |
| POST | создать ресурс или выполнить действие | нет | нет |
| PATCH | изменить часть ресурса | нет | нет |
От этих свойств зависит поведение при сбое связи. Запрос GET или DELETE клиент может повторить без последствий. Повторный POST создаст вторую запись.
§3Коды ответа
Первая цифра кода задаёт класс ответа.
| Класс | Смысл | Примеры |
|---|---|---|
| 2xx | запрос выполнен | 200 OK · 201 Created · 206 Partial Content |
| 3xx | перенаправление | 301 Moved Permanently · 304 Not Modified |
| 4xx | ошибка на стороне клиента | 400 Bad Request · 401 Unauthorized · 403 Forbidden · 404 Not Found · 429 Too Many Requests |
| 5xx | ошибка на стороне сервера | 500 Internal Server Error · 503 Service Unavailable |
> GET /api/tickets/42 HTTP/1.1
> Host: kursblinovskoy.example
> Accept: application/json
> Authorization: Bearer eyJhbGciOiJIUzI1NiJ9…
>
< HTTP/1.1 200 OK
< Content-Type: application/json; charset=utf-8
< Content-Length: 118
< Cache-Control: no-store
< Date: Wed, 07 Oct 2026 08:14:22 GMT
<
{"id": 42, "subject": "Не открывается урок 3", "status": "in_progress", "created_at": "2026-10-06T19:02:11+03:00"}Строки со знаком «>» отправил клиент, со знаком «<» — сервер. Первая строка запроса — метод, путь и версия протокола; первая строка ответа — версия и код. Ниже идут заголовки, пустая строка и тело. Заголовок Date записан в формате, который задаёт RFC 9110, а дата в теле — по ISO 8601.
198.51.100.77 - - [25/Sep/2026:04:17:52 +0300] "GET /static/backup/users.csv HTTP/1.1" 200 1148896 "-" "python-requests/2.32" │ │ │ │ │ │ │ └ программа клиента │ │ │ │ │ │ └ откуда пришёл (Referer) │ │ │ │ │ └ байт передано │ │ │ │ └ код ответа │ │ └ время запроса └ метод, путь, версия └ адрес клиента
Код 401 означает, что клиент не представился. Код 403 означает, что клиент известен, но доступа к ресурсу у него нет. Код 206 сообщает, что передана часть файла: в журнале сервера по нему видно, что файл не был получен целиком.
§4Дата и время по ISO 8601
ISO 8601 задаёт запись даты и времени от крупной единицы к мелкой: год, месяц, день, часы, минуты, секунды. Такая запись однозначна в любой стране и сортируется как текст.
| Запись | Что означает |
|---|---|
| 2026-09-16 | 16 сентября 2026 года |
| 08:14:22 | 8 часов 14 минут 22 секунды |
| 2026-09-16T08:14:22+03:00 | дата и время, местное время опережает UTC на три часа |
| 2026-09-16T05:14:22Z | тот же момент по UTC; буква Z заменяет +00:00 |
| PT24H | длительность 24 часа |
| 2026-W38 | 38-я неделя 2026 года |

§5JSON, Юникод и UTF-8
Формат JSON описан в RFC 8259. В нём шесть видов значений: объект, массив, строка, число, логическое значение и null. Комментарии и запятая после последнего элемента форматом не предусмотрены.
Правильный и неправильный JSON
{
'id': 42, // номер заявки
status: "new",
"tags": ["вход", "урок",],
"price": NaN
}{
"id": 42,
"status": "new",
"tags": ["вход", "урок"],
"price": null
}Слева пять нарушений RFC 8259: одинарные кавычки, комментарий, ключ без кавычек, запятая после последнего элемента и значение NaN, которого в JSON нет.
Юникод — стандарт, который присваивает номер каждому символу всех письменностей; тот же набор закреплён в ISO/IEC 10646. UTF-8 — способ записать эти номера байтами. RFC 8259 требует, чтобы JSON при обмене между системами был в UTF-8.

§6Частые ошибки
§7Проверьте себя
- Кто выпускает RFC и что происходит со старым документом, когда выходит новая редакция?
- Какие методы HTTP безопасны? Какие идемпотентны, но не безопасны?
- Чем отличаются коды 401 и 403? Что означает код 206?
- Запишите по ISO 8601 момент «16 сентября 2026 года, 8:14 утра по Москве».
- Чем Юникод отличается от UTF-8?
9110 — семантика HTTP8259 — JSON3339 — дата и время9457 — описание ошибкиGET, HEAD, OPTIONS — безопасныеPUT, DELETE — идемпотентные2xx 3xx 4xx 5xx401 ≠ 4032026-09-16T08:14:22+03:00Z — UTCJSON в UTF-8Юникод — набор символовСправочник «Стандарты и сертификаты» · глава 4Макаров Максим Николаевич