Как проверить post запрос

Home

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

Чтобы разобраться с POST-запросами, мы снова обратимся к Swagger Pet Store и Postman. Перейдите в Pet Store (http://petstore.swagger.io) и кликните на первом POST-запросе к «/pet». Этот POST-запрос добавит питомца в магазин. Посмотрите на Example Value (примеры значений):

Это тело POST-запроса. В отличие от GET-запросов, у которых обычно нет тела, в POST вы, как правило, найдете json или xml. Тело запроса – это данные, которые вы добавляете в базу данных. Кликните по ссылке Model:

Это окно вкратце описывает, что за значения используются в теле запроса. Вы можете нажимать на иконки «>», чтобы раскрыть каждую секцию модели. С моей точки зрения, она расплывчато описывает, что такое категория и тэги, поэтому мне придется поиграть в угадайку. Давайте пройдемся по каждой секции модели Pet:

• id: это id питомца, который можно использовать в GET-запросах, которые мы уже рассматривали.
• category: описывает, к какому виду принадлежит питомец. Id – уникальный идентификатор категории, а name – слово, описывающее животное.
• name: имя питомца.
• photoUrls: строки-ссылки на изображения питомца.
• tags: описания, которые можно добавить к питомцу. Id – уникальный идентификатор тэга, а name – слово, описывающее питомца.
• status: статус питомца в магазине. Может быть available (доступен), pending (забронирован) или sold (продан).

Мы можем использовать информацию в модели, чтобы создать POST-запрос на добавление нового питомца. Нажмите на «Try it out» и замените тело запроса следующей информацией:

< "id": 102, "category": < "id": 1, "name": "cat" >, "name": "Grumpy Cat", "photoUrls": [ "https://pbs.twimg.com/profile_images/948294484596375552/RyGNqDEM_400x400.jpg" ], "tags": [ < "id": 1, "name": "blue eyes" >], "status": "sold" >

Перед тем, как нажать на Execute, обратите внимание, что кое-что в этом POST-запросе отличается от того, с чем вы столкнетесь в ваших приложениях. Обычно при публикации объекта с id, который уже существует в базе данных, вы получите сообщение, что запись уже имеется. В случае Pet Store, если id уже есть, запись будет перезаписана данными, отправленными вами.

Теперь нажимаем на «Execute». Взгляните, что вернулось в теле ответа. Вы должны увидеть данные, которые вы добавили. Они могут отличаться порядком от тела запроса, но это не важно.

Давайте убедимся, что новый питомец действительно добавлен! Вернитесь к запросу GET pet/, откройте его и нажмите «Try it out». Введите 100 в поле ID, и нажмите на «Execute». Вы должны увидеть добавленного вами питомца в теле ответа.

Мы успешно создали запрос в Swagger, теперь давайте попробуем прогнать его в Postman. Откройте приложение и нажмите на кнопку с плюсиком «+» для создания нового запроса. Щелкните по иконке выпадающего списка рядом со словом GET, и выберите POST. Введите URL запроса: http://petstore.swagger.io/v2/pet. Нажмите на вкладку «Body» под URL и выберите опцию «Raw». В секции тела запроса ниже вставьте запрос, который мы ранее использовали в Swagger. Возможно, вам захочется его слегка изменить, поменяв id или имя питомца.

Перед тем, как отправить этот запрос через Postman, нам нужно выполнить еще одно действие – добавить заголовок. Заголовки используются в HTTP-запросах и ответах для передачи дополнительной информации серверу. В этом случае нам нужно сказать серверу, какого типа содержимого ему ожидать. Кликните на вкладке «Header» под URL, и в поле под «Key» введите «Content-Type». В поле под «Value» введите «application/json». Таким образом мы сообщаем серверу, что ему нужно искать тело запроса в json-формате. Теперь нажмите на кнопку «Send». В нижней половине окна Postman вы должны увидеть код ответа 200 и тело ответа, совпадающее с добавленными вами данными. Теперь вы можете использовать GET-запрос, чтобы убедиться, что ваш питомец добавлен.

Мы уже обсуждали тестирование форм, и тут то же самое – POST-запросы можно тестировать массой различных сценариев. Во-первых, нам надо протестировать сценарии «счастливого пути». Попробуйте отправить POST-запросы, варьируя id, категорию питомца и ее id, имя питомца, ссылки на фото, тэги и их id, и статусы питомца. Вам нужно протестировать все три статуса: sold, available и pending. Также стоит обратить внимание, что можно передавать несколько ссылок на фото, и несколько тэгов. Вот пример тела POST-запроса, где передаются три фотографии и два тэга:

< "id": 102, "category": < "id": 2, "name": "dog" >, "name": "Snoopy", "photoUrls": [ "https://schulzmuseum.org/wp-content/uploads/2017/06/920608_FlyingAce-200.jpg", "https://www.calmuseums.org/images/snoopy/snoopy.png", "https://vignette.wikia.nocookie.net/peanuts/images/2/28/AmigosperdemoSono.png/revision/latest?cb=20110823202539" ], "tags": [ < "id": 2, "name": "beagle" >, < "id": 3, "name": "flying ace" >], "status": "available" >

Теперь, когда вы протестировали ряд успешных сценариев, время задуматься о том, как можно сломать наш запрос. Во-первых, вы могли заметить по модели в Swagger, что обязательными будут только два поля: имя питомца и ссылка на фото. Что будет, если передавать только эти поля?

Мы получили ответ 200, и питомец добавлен с ID, который можно использовать, чтобы получить данные о нем. А что будет, если в теле запроса нет данных? А если нет одного из обязательных полей? Настала пора экспериментировать, передавая в запросе различные комбинации полей.

Здесь стоит отметить, что вы можете получить ответ 500 практически на любое спровоцированное вами ошибочное условие. В реальном приложении вы будете получать более точные коды ошибок и более внятные сообщения о них.

Затем стоит взглянуть на передачу нескольких ссылок и тэгов. Сколько ссылок можно передать, прежде чем начнутся ошибки? Сколько тэгов допускается передавать?

Теперь мы посмотрим на границы значений, которые мы отдаем. К примеру, что произойдет, если создать питомца с id 0? А если id будет -100000? А если id будет «FOO» или $%^? Вы можете тестировать эти значения на всех ID: питомца, категории и тэга. Насколько длинными могут быть строки? А насколько короткими? Есть ли недопустимые символы? Стоит протестировать верхние и нижние границы строк и убедиться, что запрещенные символы не принимаются сервером. Это также неплохая возможность проверить на SQL-инъекции и внедрение сценариев. К примеру, можно попробовать передать что-то вроде:

' or 1 = 1--

и посмотреть, разрешено ли это. В случае с PetStore это, скорее всего, разрешается, но реальное приложение должно запрещать такой ввод или как минимум делать его неэффективным.

Еще стоит задуматься о тестировании списка значений статуса питомца. Статус может быть одним из трех: available, pending, sold. Что произойдет, если вы передадите в статусе другое слово, число, символ? Что будет, если вы передадите статус в верхнем регистре, или если некоторые буквы будут записаны в нем? POST-запросы, как правило, нечувствительны к регистру. Стоит также проверить URL фотографии и убедиться, что в нем нельзя передать вредоносные скрипты, а также то, что не является URL.

Закончив тестировать тело запроса, переходите к заголовкам. Этому конкретному POST-запросу требуется заголовок Content-Type, позволяющий или application/json, или application/xml значение. Если заголовок отсутствует, вы получите 415 ошибку. При использовании application/xml значения вы получите ошибку 400, если только не измените тело запроса на XML-формат. Вы также можете протестировать отправку xml-тела с заголовком application/json.

И, наконец, можно протестировать URL самого запроса и его тип. Что будет, если вы сделаете запрос через https? А если измените POST на GET?

Если вкратце, есть множество способов тестирования POST-запросов, множество из которых недоступны через интерфейс. В дополнение к тестированию обязательных и необязательных полей и их валидации, вы можете также манипулировать переданным в базу объектом, заголовками, и URL запроса.

Больше информации по этой теме вы можете получить в курсе Тестирование REST API

Предыдущие статьи на эту тему

Как проверить HTTP-запрос типа POST, если серверного скрипта пока нет?

При нажатии на кнопку наблюдаю в девтулзах (на вкладке «Сеть») отправление запроса типа GET (!). Прошу помочь разобраться — почему. И — есть ли способ посмотреть тело запроса типа POST, не имея серверного скрипта. Предполагаю, что всё дело в значении атрибута «action», но — повторюсь — бэкенда пока нет. А запрос проверить очень нужно.

Отслеживать
задан 15 дек 2020 в 8:14
11 2 2 бронзовых знака

2 ответа 2

Сортировка: Сброс на вариант по умолчанию

Апач при POST-запросе на URL папки без конечного слеша, перенаправляет на URL со слешем и при этом запрос трансформируется в GET. Если же слеш поставить, то эффект пропадает.

Вывод: В action формы ставьте всегда слеш в конце URL папки, а лучше используйте URL файла.

Отслеживать
ответ дан 15 дек 2020 в 8:26
71 10 10 бронзовых знаков

Да, я это читал, спасибо. Проблема в том, что скрипта, принимающего запрос, у меня нет. Можно ли как-то без скрипта добится, чтобы «POST» был именно «POST»? Может фиктивные или тренировочные сервера есть какие-нибудь? Чей адрес я мог бы просто для эксперимента поставить?

Как проверить post запрос

Стандартная ситуация — нужно на POST выполнить некоторое действие, а на GET показать соответствующую форму. Как это сделать?

Спросил Integral
736 дн., 9 час., 4 мин. назад

Лучший ответ:

Уже забыл php) Но думаю, если ничего нового не изобрели, то как-то так:

if (isset($_POST) and $_SERVER["REQUEST_METHOD"]=="POST") 

if ($_SERVER["REQUEST_METHOD"]=="POST")

30 50 100 200 300 500 

xpp=5&xf1=0&xf2=0&xf4=0&xf5=0