-3

複数のアプリケーションで共有する予定の非常に単純な Web サービスを実装する金属エンドポイントを備えたいくつかのエンジン プラグインがあります。それらはそのままで問題なく動作しますが、明らかに、開発とテストのためにローカルにロードしているときに、Net::HTTP に get_response メッセージを送信して、localhost に現在実行中のコントローラー オブジェクト内から別のページを要求すると、即座にデッドロックが発生します。

私の質問は、Rails (または Rack) のルーティング システムは、同じサーバー インスタンスの同じアプリの一部である場合とそうでない場合がある Web サービスを安全に使用する方法を提供するか、または特別なケースをハックする必要があるかということです。 URI のホスト名が自分のものと一致する場合は、render_to_string と一緒に?

4

2 に答える 2

3

一度に 1 つの要求しか処理せず、コントローラーの要求がスタックするため、開発では機能しません。これが必要な場合は、ロード バランサーの背後で複数のサーバーをローカルで実行できます。開発でもPassengerを使用することをお勧めします ( OS X を使用している場合はprefpaneも使用します)。

私がお勧めするのは、内部 Web サービスとそれらを使用するアプリケーションを分離することです。この方法では、コードを複製せず、個別に簡単にスケーリングおよび制御できます。

于 2009-11-03T18:04:15.640 に答える
0

これは実際に可能です。ただし、呼び出すサービスが相互に再帰的に呼び出していないことを確認する必要があります。

非常に単純な「再入可能」Rack ミドルウェアは、次のように機能します。

class Reentry < Struct.new(:app)
  def call(env)
    @current_env = env
    app.call(env.merge('reentry' => self)
  end

  def call_rack(request_uri)
    env_for_recursive_call = @current_env.dup
    env_for_recursive_call['PATH_INFO'] = request_uri # ...and more
    status, headers, response = call(env_for_recursive_call)
    # for example, return response as a String
    response.inject(''){|part, buf| part + buf }
  end
end

次に、呼び出しコードで:

env['reentry'].call_rack('/my/api/get-json')

これの非常に有効な使用例は、メイン ページ内で JSON 形式の API 応答をサイドローディングすることです。

明らかに、この手法の成功は、Rack スタックの精巧さに依存します (Rack env の一部は再利用を好まないため)。

于 2015-06-05T19:28:29.730 に答える