2

わかりましたので、ルートからリクエストを取得するアプリがあります/ほとんどすべてがトラバーサルを使用しています。

しかし、そのサイトの上に残りのAPIを作りたいと思います。

だから私は2つの選択肢を持っています。それを 2 つの異なるアプリに分けて、残りのアプリケーションを :rest.site.comに配置するか、site.com/rest/*traversal に移動することができます

rest_traversal「/rest/*traversal」を実行している場合は、トラバーサル パスが route である場所という*traversal名前のルートを追加する必要があると思います/rest/*traversal。私は管理ページのために一度それをしました。

それを行うための最もクリーンな方法があるかどうか疑問に思っていました。私は virtual_root を使用しようとしましたが、私が理解しているように、virtual_root は実際にはトラバーサルのパスに追加されています。

virtual_root = /cmshave と requestのよう/funに、次のパスが作成されます/cms/fun

一方、私はなりたいと思ってい/cms/funます/fun

4

2 に答える 2

3

これはすでに回答されていることは知っていますが、「サブアプリ」を作成してピラミッドで使用する別の方法を探している人がここに到着した場合に備えて、pyramid.wsgi でいくつかの興味深いことができることを指摘したいと思います。

"""
example of wsgiapp decorator usage
http://docs.pylonsproject.org/projects/pyramid/en/1.3-branch/api/wsgi.html
"""

from pyramid.wsgi import wsgiapp2, wsgiapp
from pyramid.config import Configurator
from webob import Request, Response
import pprint

# define some apps


def wsgi_echo(environ, start_response):
    """pretty print out the environ"""
    response = Response(body=pprint.pformat({k: v for k, v in environ.items()
                                             if k not in ["wsgi.errors",
                                                          "wsgi.input",
                                                          "SCRIPT_NAME"]}))
    return response(environ, start_response)


print Request.blank("/someurl").send(wsgi_echo).body


# convert wsgi app to a pyramid view callable
pyramid_echo = wsgiapp(wsgi_echo)
pyramid_echo_2 = wsgiapp2(wsgi_echo)

# wire up a pyramid application

config = Configurator()
config.add_view(pyramid_echo, name="foo")  # /foo
config.add_view(pyramid_echo, name="bar")  # /bar
config.add_view(pyramid_echo_2, name="foo_2")  # /foo
config.add_view(pyramid_echo_2, name="bar_2")  # /bar
pyramid_app = config.make_wsgi_app()

#call some urls
foo_body = Request.blank("/foo").send(pyramid_app).body
bar_body = Request.blank("/bar").send(pyramid_app).body
foo_body_2 = Request.blank("/foo_2").send(pyramid_app).body
bar_body_2 = Request.blank("/bar_2").send(pyramid_app).body

# both should be different because we arrived at 2 different urls
assert foo_body != bar_body, "bodies should not be equal"

# should be equal because wsgiapp2 fixes stuff before calling
# application in fact there's an additional SCRIPT_NAME in the
# environment that we are filtering out
assert foo_body_2 == bar_body_2, "bodies should be equal"

# so how to pass the path along? like /foo/fuuuu should come back
# /fuuuu does it
foo_body = Request.blank("/foo_2/fuuuu").send(pyramid_app).body
assert "'/fuuuu'," in foo_body, "path didn't get passed along"


# tldr: a wsgi app that is decorated with wsgiapp2 will recieve data
# as if it was mounted at "/", any url generation it has to do should
# take into account the SCRIPT_NAME variable that may arrive in the
# environ when it is called
于 2012-08-03T18:43:15.153 に答える
1

すでにトラバーサルを使用している場合は、Pyramidがトラバーサルするときに「RESTAPIルート」オブジェクトを返すためにそれを使用してみません/rest/か？そこから、すべてが自然に機能します。

class ApplicationRoot(object):

    def __getitem__(self, name):
        if name == "rest":
            return RestAPIRoot(parent=self, name=name)
        ...

「アプリケーションツリー」と「APIツリー」に同じ子があり、子が配置されているツリーのブランチに応じて異なるビューを登録する場合は、containmentビュー述語を使用してAPIビューを登録できます。それらは、子が「APIブランチ」内にある場合にのみ一致します。

封じ込め

この値は、このビューを見つけて呼び出すために、コンテキストリソースの系統の親オブジェクトが提供する必要があるPythonクラスまたはインターフェイスへの参照である必要があります。この機能を使用するには、リソースツリー内のリソースが「ロケーション認識」である必要があります。

包含が提供されていない場合、呼び出し可能ビューを呼び出すかどうかを決定するときに、系統内のインターフェースとクラスは考慮されません。

もう1つのアプローチは、個別の「APIツリー」を構築するのではなく、「メイン」アプリケーションの「URIスペース」をRESTfulAPIとして使用することです。これに関する唯一の問題は、GETおよび場合によってはPOSTリクエストメソッドがすでにリソースで「取得」され、HTMLを返すかHTTPフォームのPOSTを消費する「通常の」ビューにマップされることです。これを回避する方法はたくさんあります。

  • APIビューを別の名前で登録します。たとえば、GET /users/123HTMLをGET /users/123/json返し、JSONオブジェクトを返します。同様に、POST /users/123HTTPフォームが投稿されることPOST /users/123/jsonを期待し、JSONを期待します。このアプローチの良いところは、たとえば、でXMLシリアライザーを簡単に追加できることですGET /users/123/xml。

  • カスタムビュー述語を使用するGET /users/123とGET /users/123?format=json、さまざまなビューにルーティングされます。実際、request_paramPyramid 1.2以降、そのための組み込みの述語があります。

  • 述語を使用してヘッダーxhrに基づいてリクエストを区別するHTTP_X_REQUESTED_WITHか、accept述語を使用してHTTP_ACCEPTヘッダーに基づいて区別します

于 2012-07-22T23:30:24.140 に答える