2012-01-10 8 views
0

は、ここで私が達成しようとしている流れです:node.jsを使用してオーディオファイルを添付している別のドメインにリクエストを送信するにはどうすればよいですか?

1)ユーザーは、サーバー1
2にオーディオファイルをアップロード)Server1には、オーディオファイルことを受け、別のドメインのサーバー2に送信し
3)Server2がオーディオファイルを変換し、サーバ2は、サーバ1がサーバ2に

スピーチテキストへの変換が行われ、ユーザにテキストを表示するバックSERVER1にテキスト
5)で応答)
4テキストします。私はオーディオファイルを送信し、応答を待っています。私はGETを使ってリクエストを送る方法を知っていますが、私はオーディオファイルでそれを使うことはできません。

node.jsを使用して別のサーバーにオーディオファイルを送信するにはどうすればよいですか?

私はnode.jsにかなり慣れているので、助けていただければ幸いです。ありがとう。

更新:
Server2はREST APIを使用しており、ファイルはPOSTされる予定です。

+0

質問を具体的なものに変更することはできますか?現在、それは広すぎて建設的な答えを形成するために使用できる詳細が欠けています。 – maerics

+0

@maerics done。それは十分具体的ですか? – Sherzod

答えて

2

リモートサーバーがオーディオファイルを受信する方法に完全に依存します。それは、ファイルの内容が一部のURLにPOST'edされていることにより、RESTfulなWebサービス・インターフェースのいくつかの並べ替えを持っていると仮定すると、あなたはこのような何かことができるかもしれない:再び

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

これはまさに私が探していたもので、あなたはそれを正しく推測しました.Server2はREST APIを使用し、そのファイルをPOSTする予定です。私はその質問を編集した。コードをテストしましょう... – Sherzod

+0

このコードで、server2からどのようにオーディオファイルにアクセスできますか?他の変数も一緒に渡していますので、すべてが名前を持っていますが、オーディオファイルは見つかりません。ありがとう。 – Sherzod

+0

@ shershams:再び、リモートサーバー上のアップロードされたファイルにアクセスする方法は、サーバーが提供するインターフェイスによってまったく異なります。あなたのHTTP POST要求への応答には、GET要求を介してファイルにアクセスするために使用できるURLまたはいくつかの識別子が含まれていると思います。 – maerics

0

これはメッセージングの良い使用例です。サーバーAに

  • サーバーAに格納ファイルを

    • ユーザー投稿ブラウザからファイル:私はこのような流れをお勧めしたいです。
    • サーバーAは、ファイルをテキストに変換するジョブを作成し、それをジョブキューに送信します。ジョブには、ファイルの場所が含まれています。
    • サーバAはチャネル(PubNubまたはPusherなど)を作成します。
    • サーバーAは、ブラウザにチャネルIDを返します。
    • サーバBは実際にはキュー上でリッスンするプールです(多くのワーカーになることがあります)。
    • プール・ワーカーがジョブをキューから取り出して処理します。
    • プールワーカーはテキストファイルを保存します。
    • プールワーカーは、テキストファイルの場所および/または本文を含むチャネルIDにメッセージを送信します。
    • ブラウザは、メッセージ通知を取得し、それをユーザーに示す

    サーバーAとサーバーBとの間の直接のHTTP通信のいくつかの弱点がある:APIとサーバのエンドポイント間

    • 密結合AとサーバーB.
    • サーバAとサーバBは互いにどのように通信する許可を与えられていますか?
    • サーバーBをしばらくダウンする必要がある場合はどうなりますか?メッセージキューでは、サーバーBがバックアップされるまでジョブが蓄積され、その後再開されます。 HTTP通信では、サーバーBが再開するまで失敗します。
    • さらにサーバーBを追加する必要がある場合はどうすればよいですか?現在、HTTPリバースプロキシ、ロードバランシングなどを使いこなしています。メンテナンスのためにServer Bsをダウンさせるという問題は複雑になります。
  • 関連する問題