Как отправить запрос в другой домен с вложением аудиофайла с помощью node.js? - PullRequest
0 голосов
/ 10 января 2012

Вот поток, который я пытаюсь достичь:

1) Пользователь загружает аудиофайл на сервер1
2) Сервер1 получает этот аудиофайл и отправляет его на сервер2 в другом домене
3) Сервер2 преобразует аудиофайл в текст
4) Сервер2 отвечает обратно на сервер1 текстом
5) Сервер1 отображает текст для пользователя

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

Как отправить аудиофайл на другой сервер с помощью node.js?

Я довольно новичок в node.js, поэтому любая помощь будет принята с благодарностью.Спасибо.

ОБНОВЛЕНИЕ:
Сервер2 использует REST API и ожидает, что файл будет POST'ед.

Ответы [ 2 ]

2 голосов
/ 10 января 2012

Это полностью зависит от того, как удаленный сервер ожидает получить аудиофайл. Предполагая, что у него есть некоторый интерфейс веб-службы RESTful, посредством которого содержимое файла переносится по некоторому URL, вы можете сделать что-то вроде этого:

fs.readFile('/path/to/my/audiofile.wav', function (err, data) {
  if (err) throw err;
  var options = {
    host: 'remotehost.com',
    path: '/upload/wav',
    method: 'POST',
    headers: { 'Content-Type': 'audio/wav' }
  };
  var req = http.request(options, function(res) {
    // Handle a successful response here...
  });
  req.on('error', function(e) {
    // Handle an error response here...
  });
  // Write the audio data in the request body.
  req.write(data);
  req.end();
});

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

0 голосов
/ 12 января 2012

Это хороший вариант использования для обмена сообщениями. Я бы предложил такой поток:

  • Пользователь отправляет файл из браузера на сервер A.
  • Сервер A хранит файл.
  • Сервер A создает задание для преобразования файла в текст и отправляет его в очередь заданий. Задание содержит местоположение файла.
  • Сервер A создает канал (например, PubNub или Pusher).
  • Сервер A возвращает идентификатор канала в браузер.
  • Сервер B на самом деле является пулом (может быть много рабочих), слушающим в очереди.
  • Работник пула снимает задание с очереди и обрабатывает его.
  • Работник пула сохраняет текстовый файл.
  • Работник пула отправляет на идентификатор канала сообщение с указанием местоположения и / или тела текстового файла.
  • Браузер получает сообщение с уведомлением и показывает его пользователю

Некоторые недостатки прямой HTTP-связи между Сервером A и Сервером B:

  • Тесная связь между API и конечными точками Сервера A и Сервера B.
  • Как серверу A и серверу B предоставлено разрешение на общение друг с другом?
  • Что произойдет, если сервер B будет временно отключен? При наличии очереди сообщений задания накапливаются до тех пор, пока сервер B не будет восстановлен, а затем возобновятся. При обмене данными по HTTP возникают сбои, пока сервер B не возобновит работу.
  • Что делать, если вам нужно добавить больше серверов B? Теперь вы возитесь с обратными прокси-серверами HTTP, балансировкой нагрузки и т. Д., И ваша проблема снятия Server B для обслуживания осложняется.
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...