От чего зависит совпадение тела HTTP запроса и тела ответа

Что проверяют

Понимаете ли вы, что ответ сервера не обязан повторять запрос, и умеете ли строить проверку от контракта, а не от ожидания «что послал, то и вернулось». Вопрос почти всегда ведёт к обсуждению того, как вы пишете автотесты на API.

Как отвечать

Начните с того, что совпадение это не свойство протокола, а решение конкретного API. HTTP только переносит тело, а что окажется в ответе, задаёт контракт: POST может вернуть созданный объект, а может отдать 201 с заголовком Location или 204 вообще без тела.

Дальше перечислите, что закономерно расходится:

• серверные поля: идентификатор, версия, даты создания и изменения, значения по умолчанию;
• нормализация: обрезка пробелов, приведение регистра, формат телефона, округление дробных, приведение дат к UTC;
• фильтрация: поля только для чтения сервер игнорирует, секреты не возвращает вовсе;
• сериализация: порядок ключей, отсутствующее поле против null, экранирование не-ASCII символов.

Проверять нужно по спецификации: валидация ответа схемой, сравнение значимых полей поимённо, отдельный GET после записи, чтобы убедиться, что данные действительно сохранились в том виде, в каком их вернули.

Где спотыкаются

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

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

Сравнивают сырые строки вместо разобранного JSON. Порядок ключей, пробелы, экранирование кириллицы и хвостовой ноль в числе дают красный тест на полностью корректном ответе.