Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Calling API from inside Resource handler? #1228

Open
jcampanello opened this issue Mar 7, 2018 · 2 comments
Open

Calling API from inside Resource handler? #1228

jcampanello opened this issue Mar 7, 2018 · 2 comments

Comments

@jcampanello
Copy link

Hi,
is there a simple way to call an API method from inside a resource Handler?
I'm implementing an API that has HATEOAS _embedded (which includes content for performance reasons). Ex:
{ ... data ..., "_embedded" : { "/session" : { ... data for GET /session ... } } }
For what i can see, the testing classes have a way to emulate a WSGI call, but not sure if there is a way to make requests to the main API for routing and all.

Any help appreciated!

@kgriffs
Copy link
Member

kgriffs commented May 8, 2018

Hi @jcampanello, sorry for the delay in responding. There's no feature for internal routing currently, although you can certainly just call the on_* responder method directly, or factor out the logic to a third method. I'll schedule this as a possible feature for 2.x since we've been getting a number of requests along these lines.

@kgriffs kgriffs added this to the Version 2.x milestone May 8, 2018
@jcampanello
Copy link
Author

Kurt, never mind for the delay :-)

I actually took the code from the tests to implement API call with WSGI emulation. I think this provides for better modularity, otherwise a module implementing part of the API should know about other modules implementing other parts (granted, the API path is coupling, but could be passed as a parameter on handler creation).

The most important benefit of this approach, i think, is when you make the request through WSGI emulation you get to benefit from all the middleware installed in the API. Ex: user and customer access control (is customer paying for the salary module and does user X has permissions to access salary module), middleware level caching, ip access control, etc.

This derives into an important requirement (for my implementation, at least) that to make the simulated request, i should start from the current request (and response) and copy at least header fields (except: CONNECTION, QUERY_STRING, session, ACCEPT-ENCODING, COOKIE, CONTENT-LENGTH, CONTENT-TYPE) and the cookies. This is to support authentication tokens, host identifiers, api special headers, etc. The current response is required because some cookies could be set on it that should go in the next requests (as if the actual client made it).

Well, i've wrote this only in case you decide to add it as a feature, to state some things i think should probably be considered.

Thanks for the response (and for falcon!). Regards

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants