Какие HTTP методы можно использовать для тестирования POST-запроса

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

Для Android-разработчика это вопрос о том, как вы убеждаетесь, что приложение отправляет правильный POST и корректно обрабатывает ответ. Следом часто спрашивают, как тестировать сетевой слой без живого бэкенда и что будет при повторной отправке.

Как отвечать

Коротко про методы вокруг POST: сам POST создаёт ресурс и не идемпотентен, GET после него подтверждает, что данные сохранились, PUT и PATCH меняют созданное, DELETE убирает. На неподдерживаемый метод сервер должен ответить 405.

Дальше переходите к своему стеку, это главное:

• Retrofit: метод задаётся аннотацией @POST, тело через @Body с конвертером kotlinx.serialization или Moshi, формы через @FormUrlEncoded и @Field, файлы через @Multipart;
• MockWebServer из OkHttp: в тесте поднимаете локальный сервер, ставите в очередь ответ, вызываете репозиторий и через takeRequest() проверяете метод, путь, заголовки и тело. Так ловятся ошибки сериализации: поле с неверным именем или null там, где бэкенд ждёт отсутствие ключа;
• ответы сервера: 201, 400 с телом ошибки, 401 с обновлением токена в Authenticator, 5xx и таймаут. Экран должен показать понятное состояние, а не упасть на парсинге;
• ручная проверка: Network Inspector в Android Studio, Charles или Proxyman для подмены ответов.

Отдельно про повторы. POST из WorkManager при плохой сети может дойти до сервера дважды: запрос прошёл, а ответ потерялся. Защита это ключ идемпотентности в заголовке, который клиент генерирует один раз на операцию и хранит до успеха.

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

Отвечают как тестировщик API и ни слова не говорят о клиенте: Retrofit, сериализация, обработка ошибок.

Тестируют сеть только против настоящего стенда. Такие тесты медленные и падают из-за чужих данных, а MockWebServer даёт воспроизводимый результат.

Не думают о повторной отправке и получают дубли заказов после ретраев.