1 В избранное 0 Ответвления 0

OSCHINA-MIRROR/bieber-smartpost

Клонировать/Скачать
Внести вклад в разработку кода
Синхронизировать код
Отмена
Подсказка: Поскольку Git не поддерживает пустые директории, создание директории приведёт к созданию пустого файла .keep.
Loading...
README.md

Данный проект представляет собой инструмент-прокси для HTTP-запросов, который позволяет осуществлять управление вводом данных запросов, их комбинирование и автоматическое сохранение cookie, возвращаемых службой. При объединении нескольких запросов информация о cookie, полученная в ответ на предыдущие запросы, будет передаваться серверной части в последующих запросах.

Инструмент был разработан с целью упрощения тестирования RESTful интерфейсов. На текущий момент реализована только базовая функциональность, в дальнейшем планируется её доработка на основе полученного опыта.

Основное описание функций

Ввод базовой информации

Эта функция предназначена для ввода данных запроса в Smartpost. Вводимая информация включает заголовки HTTP-запроса, метод запроса (POST/GET) и параметры запроса.

Описание настройки параметров запроса

Smartpost поддерживает ввод параметров запроса через форму (form), где параметры представлены в виде пар «ключ-значение». Если используется метод POST, то данные отправляются на сервер в формате key1=value1. Если же используется метод GET, то пары «ключ-значение» добавляются к URL запроса. Помимо ввода параметров через форму, также поддерживается ввод в форматах json, xml, html и text. Если выбран формат json, то отправляемый на сервер тип содержимого (Content-type) будет равен application/json;charset=UTF-8, и так далее: для xml — application/xml;charset=UTF-8; для text — text/plain;charset=UTF-8; а для html — text/html;charset=UTF-8. Поэтому после выбора типа параметра, отличного от формы, нет необходимости устанавливать атрибут Content-type в заголовке, если у вас нет особых требований.

Сценарии использования

В процессе разработки нам часто требуется отправить несколько URL-запросов для отладки интерфейса. Например, процесс просмотра товара может включать следующие шаги:

  1. Открыть главную страницу интернет-магазина.
  2. Просмотреть товары. Здесь задействованы как минимум два URL-адреса (главная страница и страница товара). Эти два запроса можно объединить в один сценарий в Smartpost, который можно назвать «Просмотр товара». Вы можете выполнить этот сценарий, и запросы будут отправлены по указанным URL в заданном порядке, возвращая результаты выполнения.

Smartpost здесь просто объединяет запросы. Но этого недостаточно, поскольку между этими запросами существует определённая связь. Предположим, что адрес интернет-магазина (назовём этот запрос request_index) следующий:

http://www.smpmall.com Это адрес главной страницы, где отображаются различные товары. Обычно мы выбираем конкретный товар, и предположим, что структура главной страницы следующая:

<title>Главная страница</title>
Допустим, я выбираю item-1222.html в Smartpost, как это сделать? Достаточно определить этот запрос как (назовём его request_item): http://www.smpmall.com/#{html:'#items .item a&[attr:href]'[0]} После выполнения запроса request_index, Smartpost извлечёт содержимое item-1222.html из возвращённого HTML и заменит выражение #{html:'#items .item a&[attr:href]'[0]}.

Здесь проявляется контекстная зависимость запросов в Smartpost, что делает необходимым создание сценариев. Разработчики могут использовать эти сценарии для тестирования бизнес-процессов. Ниже описывается конфигурация заполнителей на основе контекста.

Конфигурация заполнителей на основе контекста

Конфигурация заполнителей в Smartpost состоит из нескольких частей:

#{type:'expression'[index][default:defaultvalue]}
где type может быть одним из следующих: html, json, header, cookie
expression — это правило соответствия для текущего типа. Например, если type равен header, то expression представляет ключ в заголовке
[index] — это необязательная конфигурация, которая указывает, какой из совпадающих элементов выбрать, если их несколько
[defalut:defaultvalue] — также необязательная конфигурация, указывающая значение по умолчанию, если не найдено совпадение с выражением
Ниже приводится описание выражения для каждого типа:

1. Тип header

Этот пример уже был приведён ранее. Когда type равен header, expression представляет значение ключа в заголовке. Заполнитель будет заменён значением соответствующего ключа.

2. Тип cookie

Аналогично типу header, но значения берутся из возвращаемых cookie.

3. Тип json

В этом случае expression является выражением JSONPATH, конкретные правила которого можно найти здесь: https://github.com/jayway/JsonPath

4. Тип html

Выражение здесь состоит из двух частей: первая — это CSS-селектор, используемый для указания HTML-элемента, а вторая — значение этого элемента. Структура такова: cssselector&[text|val|attr:attrName]. Что касается первой части (cssselector), то она должна быть знакома всем. Рассмотрим вторую часть &[text|val|attr:attrName]: Например, #{html:'#items .item a&[attr:href]'[0]} означает, что выбирается значение атрибута href первого элемента, соответствующего селектору #items .item a. Только при выборе attr необходимо указать, какое именно значение атрибута нужно извлечь.

Комментарии ( 0 )

Вы можете оставить комментарий после Вход в систему

Введение

Этот проект представляет собой HTTP-клиентский прокси для запросов. Он позволяет осуществлять управление информацией о запросах, их комбинирование и автоматическое сохранение cookie, полученных в ответ на запросы. При объединении нескольких запросов информация о cookie, возвращённых в ответ, будет передана серверной части в последующих запросах.... Развернуть Свернуть
Apache-2.0
Отмена

Обновления

Пока нет обновлений

Участники

все

Недавние действия

Загрузить больше
Больше нет результатов для загрузки
1
https://api.gitlife.ru/oschina-mirror/bieber-smartpost.git
git@api.gitlife.ru:oschina-mirror/bieber-smartpost.git
oschina-mirror
bieber-smartpost
bieber-smartpost
master