Почему response.json( ) после fetch асинхронен?

Question

[stan288]

Во время работы с Fetch api возник вопрос, почему response.json( ) возращает промис? Мы ведь не посылаем никаких данных на сервер, просто нужно распарсить json, который мы получили в ответе от сервера. Для чего так было сделано? Объясните пожалуйста недалёкому

Comments

[Aetae]

Ответ Vindicar верен, но так как он звучит неуверенно, напишу: когда мы делаем fetch - и получаем responce - это значит что мы получили ответ от сервера, но ещё не получили всё содержимое ответа(потому что интернет по проводам течёт не моментально). На этом этапе нам уже доступен статус и заголовки ответа, с которыми мы можем произвести какие-то действия(например если статус 404 - не пытаться читать ответ). Соответственно .json() уже ждёт полной загрузки и выполняет JSON.parse над ним.
Конечно если запрос маленький, то на этапе получения response загрузка может быть и целиком завершена, но не было никакого смысла выделять это в особый случай.

В принципе всё это ты мог бы узнать открыв любой учебник по js на соответствующей теме.

[WbICHA]

Aetae,

В принципе всё это ты мог бы узнать открыв любой учебник по js на соответствующей теме.

Ну, это относится к 99% вопросов здесь.)

[Вадим]

ну добавлю разве что, что в промис можно обернуть любую "синхронную" операцию, у которой есть некоторая длительность выполнения и резолвить промис, по факту завершения этой операции.

И ещё как пример, есть подход построения последовательных анимаций через промисы.
Что-то вроде:

animation1()
  .then(animation2)
  .then(animation3)
  .then(showSubmitPopup)

Answer 1

[Inviz Custos]

Для чего так было сделано?

Все сделано логично и правильно. fetch() возвращает ответ как только все заголовки были прочитаны (не дожидаясь при этом получения полезной нагрузки). Если же надо получить и полезную нагрузку, то в ответе есть стрим, из которого уже читаете что Вам нужно (и сколько нужно).
Все остальные методы ( Response.json(), Response.text() и т.д ) являются просто хелперскими обертками над стримом и соответственно будут асинхронными.

Таким образом мы не делаем лишней работы и получаем тело ответа только в том случае, если оно нам действительно надо.

Answer 2

[Сергей Соколов]

Посмотрите, как выглядит «текстовый чат» по протоколу HTTP, когда клиент запрашивает у сервера что-то, и получает ответ.

Примерная очерёдность:
Код на клиенте вызывает fetch(). Устанавливается соединение, передаётся запрос «дай /api/method» и передаются заголовки, типа «готов принять json».

Сервер обрабатывает, думает и «пишет в чат»:
1) Строку со статусом HTTP/1.1 200 OK – мол, норм, ща всё будет.
2) Несколько строк HTTP-заголовков ответа: размер, тип и пр.
Пустую строку – мол, заголовки всё.

Вот в этот момент fetch уже понимает, как у него дела с этим запросом. И ресолвит первый промис. Уже ясно, что вроде всё ок, ща польют данные, и это надолго. Дальше вступает в работу объект Response.

3) После пустой строки после заголовков ответа, сервер начинает лить данные тела ответа. Может пару букв, а может гигабайт дампа. Представьте медленный интернет, зарезанную скорость «недружественного» сайта и т.п.

Данные медленно ползут... И наконец, полностью переданы-получены.

Вот тут у объекта Response ресолвится его .json() промис. Посмотрите по ссылке — у того же объекта (мы его получаем после первого ресолва fetch()) есть и свойства, доступные сразу же, синхронно: например, объект с заголовками: свойство headers. Или свойство ok, значение которого следует из самой первой строки ответа сервера.

В общем, понять асинхронность помогает (мысленное) замедление всего и вся. Как будто интернет медленный, вычисления выполняются вручную на бумажке с калькулятором. Становится ясно, что какие-то потенциально долгие делишки ждать невесело, поэтому их делают асинхронными: сразу возвращают Promise, который отресолвится когда там всё доделается. А пока ждём, можно и салат оливье нарезать )

Answer 3

[Алексей Ярков]

Мы ведь не посылаем никаких данных на сервер

По вашему получается, что асинхронной должна быть только передача и получение данных с сервера ))
Куча браузерного API работает асинхронно, используя промисы.
Конкретно про response.json( ). Ответ от сервера может быть весьма немаленьким и логично, что его чтение стоит сделать асинхронным. Но это моё предположение.

Comments

[studentRrontend]

response.json() не возвращает JSON, он – декодирует ответ в формате JSON.

[Сергей Соколов]

studentRrontend, декодирование само по себе синхронно как обычный JSON.parse()
Асихронность тут именно из-за того, что поток данных ещё не весь принят.

fetch() ресолвится в объект Response. У того есть свойство body, которое можно прочесть сразу. Но это не принятные данные, а ReadableStream, который можно читать только асинхронно.

[Алексей Ярков]

если ответ помог, то можете пометить решением )) Это лучшее спасибо на этом ресурсе.

Answer 4

[Vindicar]

Потому что получение ответа от сервера - не то же самое, что получение контента. Скорее всего, мы получили только заголовки ответа, а в рамках соответствующих методов типа json() мы получаем тело ответа и парсим его.