Перехватывать запросы и автоматически генерировать команду curl

При получении ошибок, возникающих в результате HTTP-запросов веб-API, очень часто начинают исследовать проблему, извлекая точный запрос, который делает приложение, и подготавливая команду curl или вызов почтальона для воспроизведения проблемы.

ПОСТ ОБНОВЛЕНИЕ

Если вы здесь только потому, что ищете простой способ регистрации своих HTTP-вызовов, вы можете использовать этот пакет NuGet, который я создал в этом посте.

Но если вы здесь, чтобы лучше понять, как это работает, это даже лучше, наслаждайтесь этим.

Это не сложная задача, но она требует много времени, так как нам нужно запустить наши приложения, чтобы идентифицировать запрос, проверить адрес, параметры, заголовки, ключи и т. д., скопировать их в файл и создать команду curl.

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

В этой статье я покажу, как использовать Обработчики HTTP-сообщений для перехвата HTTP-запросов и автоматического создания команд curl для ваших запросов очень простым и быстрым способом.

Подождите, для этого не нужен специальный код.

Если вы думаете о родных обработчиках журналов HTTP в Asp.Net 6.0, вы абсолютно правы, нам не нужен собственный код.

Если вы используете Asp.Net 6.0, ознакомьтесь с документацией здесь и логируйте все ваши запросы даже проще, чем представленные методики и эта статья

Но если вы используете более старые версии, такие как 5.0 или 3.1 (или старше), возможно, эта статья может быть вам полезна.

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

Обработчики HTTP-сообщений

Обработчик HTTP-сообщений — это класс, который получает HTTP-запрос и возвращает HTTP-ответ (просто так).

Веб-API Asp.Net имеет несколько встроенных обработчиков сообщений, которые создают конвейер вложенных (и собственных) вызовов.

Мы можем создать собственный обработчик, унаследованный от класса DelegatingHandler, и добавить его в конвейер.

Бесплатные тестовые API

Прежде чем приступить к созданию нашего примера веб-API, я искал бесплатные API для использования в своих тестах и нашел два довольно интересных:

  • Национализация ввода-вывода — этот API использует метод GET и предсказывает национальность человека по имени.
  • API-переводчик Yoda — API-интерфейс переводчика Yoda использует метод POST и переводит английскую фразу на язык Yoda, что в основном приводит к обратному исходному предложению.

Итак, на основе этих двух API мое предложение состоит в том, чтобы создать новый веб-API, который по имени предсказывает национальность человека и запрашивает у переводчика Yoda фразу Master {NAME} has lost {COUNTRY} и ожидает результат вроде Lost {COUNTRY}, master {NAME} has

Красиво и просто — нет, так что давайте создадим его.

Создание веб-API

Создайте новую папку на нашем компьютере, введите mkdir http-to-curl в командной строке и нажмите Enter.

Затем войдите в папку с запущенным cd http-to-curl и создайте новый веб-API с запущенным dotnet new webapi.

Теперь давайте установим зависимости Refit, чтобы иметь возможность легко делать запросы с ним, запускаем dotnet add package Refit --version 6.3.2 и dotnet add package Refit.HttpClientFactory --version 6.3.2

Откройте код Visual Studio с запущенным code ., и структура должна быть очень похожа на эту:

Затем создайте новую папку API и добавьте INationalizeApi.csclass

Также добавьте IYodaTranslationApi.csclass

Затем добавьте клиентов переоснащения в файл Program.cs (строки 10 и 14):

Удалите класс WeatherForecastController и WeatherForecast и добавьте класс CompositeApiController, как показано ниже.

Наш API готов к запуску, введите dotnet run в консоли и сделайте запрос, набрав curl --location --insecure --request GET 'https://localhost:7127/Pietro' --header 'keya:valuea' --header 'keyb:valueb' (обратите внимание, что заголовки приведены только для примера, небезопасный вариант — избежать сертификата и, возможно, вам нужно будет адаптировать порт к тому же как ваше приложение работает)

Если все в порядке, вы увидите следующее сообщение о результате в командной строке: Lost italia, Pietro has

Миссия выполнена, у нас есть пример приложения.

Преобразование запросов в завитки

Теперь приготовьтесь к самой важной части: давайте создадим наш собственный обработчик, создадим логику для проверки запроса и создадим curl.

Этот класс очень простой, во-первых, мы переопределяем метод SendAsync, который будет выполняться до того, как произойдет запрос, а для перехвата здесь в основном нужно будет добавить методы для логирования запроса и ответа.

Чтобы упростить поиск в журналах, я создаю GUID, который упростит сопоставление запросов с ответами в журналах.

Методы журнала также очень просты, они начинают регистрировать некоторый синтаксис curl жесткого кода, затем регистрируют адрес, метод, заголовки и тело объекта запроса.

Главное здесь в том, что он должен быть полностью настраиваемым, и вы можете делать все, что захотите.

Последний шаг — связать обработчики с нашим клиентом Refit, для этого нам нужно добавить в Program.cs вызов метода .addHttpMessageHandler<HttpToCurlHandler> для каждого вызова Refit, который можно использовать в обработчике (строки 4 и 9), и зарегистрировать обработчик в услуги (строка 11)

Адаптация нашего существующего кода для использования обработчика должна выглядеть примерно так:

Проверка журналов

Поскольку я использую метод System.Diagnostics.Debug.WriteLine() для регистрации, мы сможем видеть журналы только при запуске приложения в режиме отладки, если вам нужно что-то другое, вам нужно только изменить способ, которым обработчик регистрирует информацию.

Нажмите F5, чтобы запустить приложение в режиме отладки, и повторите запрос, как мы делали на предыдущем шаге.

Заглянув в окно Debug Console и отфильтровав REFIT LOG, вы сможете увидеть все завитки, сгенерированные обработчиком.

Да, это работает.

Другое использование

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

Пример проекта и заключительные соображения

Если вы хотите запустить пример проекта, который я использовал для создания этой статьи, не стесняйтесь клонировать его из моего репозитория GitHub.

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