В Rails можно ли сгенерировать внутренний запрос, который ведет себя идентично HTTP-запросу?

Question

В моем приложении на Rails я хотел бы генерировать запросы, которые идентичны «подлинным» HTTP-запросам.

Для несколько надуманного примера, предположим, что я создавал систему, которая могла бы пакетировать входящие HTTP-запросы для дальнейшей обработки. Интерфейс для него будет примерно таким:

1. Создайте новый пакетный ресурс с помощью обычной методологии CRUD (POST, получите местоположение для вновь созданного ресурса).
2. Обновите пакетный ресурс, отправив ему URL-адреса, методы HTTP и данные, которые будут добавлены в коллекцию запросов, которые он должен впоследствии выполнить массовым образом.
3. «Обрабатывает» пакетный ресурс, в котором он будет перебирать свою коллекцию запросов (каждый из которых может быть представлен URL-адресом, методом HTTP и набором данных) и каким-то образом указывать Rails обрабатывать эти запросы в так же, как и при поступлении обычных, «не пакетированных» запросов.

Мне кажется, что для того, чтобы сделать это функциональным, необходимо выполнить две важные работы:

Во-первых, входящие запросы нужно как-то сохранить на потом. Это может быть просто случай сохранения различных аспектов входящего запроса, таких как путь, метод, данные, заголовки и т. Д., Которые уже представлены как часть объекта входящего запроса в контроллере. Было бы неплохо, если бы существовал более «автоматический» способ обработки этого - возможно, что-то более похожее на маршалинг объектов или сериализацию - но подход «грубой силы» записи отдельных параметров также должен работать.

Во-вторых, сохраненные запросы должны иметь возможность повторно вводиться в приложение rails позднее и проходить через тот же процесс, что и обычный HTTP-запрос: маршрутизация, контроллеры, представления и т. Д. I ' Я хотел бы иметь возможность захватить ответ в строке, так же, как его увидел бы клиент HTTP, и я также хотел бы сделать это, используя внутренний механизм Rails, а не просто используя библиотеку HTTP, чтобы приложение буквально создавало новый запрос к себе.

Мысли

Answer 1

Стойка Middleware

Проведя много исследований после того, как я первоначально задал этот вопрос, я в конечном итоге экспериментировал и успешно внедрил решение с использованием Rack Middleware.

Основная методология

В методе промежуточного программного обеспечения `call ':

1. Проверьте, делаем ли мы запрос как вложенный ресурс объект транзакции, или если это обычный запрос. Если это обычный, продолжайте как обычно через промежуточное ПО, позвонив app.call (env) и возвращает статус, заголовки и ответ.

2. Если это не фиксация транзакции, запишите "интересные" части запросите хэш env и сохраните их в базе данных как «операцию», связанную с этим объектом транзакции.

3. Если это фиксация транзакции, извлеките все соответствующие операции. для этой транзакции. Либо создайте новую среду запросов, либо клонируйте существующего и заполните его значениями, сохраненными для операции. Также сделать копию исходной среды запроса для последующего восстановления, если управление должно проходить через приложение, как правило, после фиксации.

4. Подайте созданную среду в вызов app.call (env). Повторите для каждая операция.

5. Если исходная среда запроса была сохранена, восстановите ее и создайте последний вызов app.call (env), возвращающийся из вызова `call 'в промежуточное ПО - статус, заголовки и ответ на этот последний вызов app.call (окр).

Пример приложения

Я реализовал пример реализации методологии, которую я описал здесь, которую я сделал доступной на GitHub. Он также содержит подробный пример, описывающий, как реализация может выглядеть с точки зрения API. Имейте в виду: это довольно грубо, совершенно недокументировано (за исключением README) и, возможно, нарушает хорошие практики кодирования Rails. Его можно получить здесь:

• http://github.com/mcwehner/transact-example

Плагин / Gem

Я также начинаю работу над плагином или гемом, который предоставит такой интерфейс любому приложению Rails. Он находится в стадии формирования (на самом деле на данный момент он полностью лишен кода), и работа над ним, вероятно, будет продолжаться медленно. Исследуйте его, как он развивается здесь:

• http://github.com/mcwehner/transact

Смотри также

• Railscasts - промежуточное программное обеспечение для стойки
• Направляющие рельсов - Рельсы на стойке

Answer 2

прямой способ хранения аргументов должен сериализовать объект запроса в вашем контроллере - он должен содержать все важные данные

для вызова запросов позже, я хотел бы рассмотреть возможность использования метода класса Dispatcher.dispatch, который принимает 3 аргумента: запрос cgi, параметры сеанса (CgiRequest :: DEFAULT_SESSION_OPTIONS должен быть в порядке) и поток, в который записывается вывод до