Re: What's the best way to simulate a request?
To simulate requests I am using following code and works perfect for me:
from django.test.client import Client
c = Client()
response = c.get('/url/you/want/to/request')
On Tuesday, July 8, 2008 7:16:54 AM UTC+5:30, Andrew wrote:
>
> Here's the situation:
>
> I'm creating an RESTful internal API as an app in our project. Our
> 'main' app (we'll call it main) is a client of the API app. Since
> we're building the API piece by piece as we use it, the emphasis on
> all of this is simple simple simple -- with our eye on eventually
> opening up pieces of the API to the public.
>
> The general flow looks like:
> request => main app handling => API client => API logic.
>
> Because right now both of the apps live in the same project and are
> being served from the same boxes (and the API won't be running on a
> separate machine for a while), I figured, hey, why not just fake an
> HttpRequest from the main app logic and pass it over to API? That way,
> we don't need to worry about exposing the internal URLs, we don't need
> to worry about authentication right now, it'll be simple.
>
> Right now the API client I've written takes an HTTP method, path, and
> params, uses resolve(path, api.urls) to get the view, and then calls
> the view using a fake HttpRequest that I populate myself.
>
> The one problem is that I'm finding it much harder to fake the
> HttpRequests than I thought -- namely because the RESTful handlers on
> the API side are expecting things like request._get_post_and_files()
> to be present.
>
> So, my thoughts:
> a) Continue using the lightweight API "client" I've written, but
> instead of building a HttpRequest, fake a WSGIRequest instead (with
> the _minimum_ data needed)
> b) Patch the django test client to deal with PUT and DELETE and use
> that as our API client
> c) Import the API urls.py into the main urls.py and call the API
> methods by generating actual HTTP requests
>
> I'm not crazy about c) since it requires more infrastructure work now.
>
> Any thoughts?
>
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/django-users/-/anK1ji7axM8J.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: What's the best way to simulate a request?
Andrew wrote: > Here's the situation: > > I'm creating an RESTful internal API as an app in our project. Our > 'main' app (we'll call it main) is a client of the API app. Since > we're building the API piece by piece as we use it, the emphasis on > all of this is simple simple simple -- with our eye on eventually > opening up pieces of the API to the public. > > The general flow looks like: > request => main app handling => API client => API logic. > > Because right now both of the apps live in the same project and are > being served from the same boxes (and the API won't be running on a > separate machine for a while), I figured, hey, why not just fake an > HttpRequest from the main app logic and pass it over to API? That way, > we don't need to worry about exposing the internal URLs, we don't need > to worry about authentication right now, it'll be simple. > > Right now the API client I've written takes an HTTP method, path, and > params, uses resolve(path, api.urls) to get the view, and then calls > the view using a fake HttpRequest that I populate myself. > > The one problem is that I'm finding it much harder to fake the > HttpRequests than I thought -- namely because the RESTful handlers on > the API side are expecting things like request._get_post_and_files() > to be present. > > So, my thoughts: > a) Continue using the lightweight API "client" I've written, but > instead of building a HttpRequest, fake a WSGIRequest instead (with > the _minimum_ data needed) > b) Patch the django test client to deal with PUT and DELETE and use > that as our API client > c) Import the API urls.py into the main urls.py and call the API > methods by generating actual HTTP requests > > I'm not crazy about c) since it requires more infrastructure work now. > > Any thoughts? Yeah, give more than lip service to "simple simple simple". You say that then outline how you are reimplementing HTTP because you don't want to be "exposing the internal URLs" yet. I suggest spending an hour, a day learning about how your webserver(s) handle auth and start using it. My $.02US (only about .01 at today's rates) Baring that, option B is best since the code will at least be useful for tests. Where as the other options' code become mostly worthless once you start using real requests. -- Norman J. Harman Jr. Senior Web Specialist, Austin American-Statesman ___ You've got fun! Check out Austin360.com for all the entertainment info you need to live it up in the big city! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
What's the best way to simulate a request?
Here's the situation: I'm creating an RESTful internal API as an app in our project. Our 'main' app (we'll call it main) is a client of the API app. Since we're building the API piece by piece as we use it, the emphasis on all of this is simple simple simple -- with our eye on eventually opening up pieces of the API to the public. The general flow looks like: request => main app handling => API client => API logic. Because right now both of the apps live in the same project and are being served from the same boxes (and the API won't be running on a separate machine for a while), I figured, hey, why not just fake an HttpRequest from the main app logic and pass it over to API? That way, we don't need to worry about exposing the internal URLs, we don't need to worry about authentication right now, it'll be simple. Right now the API client I've written takes an HTTP method, path, and params, uses resolve(path, api.urls) to get the view, and then calls the view using a fake HttpRequest that I populate myself. The one problem is that I'm finding it much harder to fake the HttpRequests than I thought -- namely because the RESTful handlers on the API side are expecting things like request._get_post_and_files() to be present. So, my thoughts: a) Continue using the lightweight API "client" I've written, but instead of building a HttpRequest, fake a WSGIRequest instead (with the _minimum_ data needed) b) Patch the django test client to deal with PUT and DELETE and use that as our API client c) Import the API urls.py into the main urls.py and call the API methods by generating actual HTTP requests I'm not crazy about c) since it requires more infrastructure work now. Any thoughts? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
