can I write Django a client consuming RESTfull api from elsewhere

[kk]

Dear all,
I wish to know if I need to do some thing special for consuming a
RESTfull server from some other provider?
What should I do in the views?
Do I need the complete DRF to do this?
Can I do this with just Django's views and then send data across to
templates?
I mean, can I write views to connect and call the API, send and receive
data and then send the output to the templates?
The encoding is in json when interacting with the remote REST API.
happy hacking.
Krishnakant.

[Avraham Serour]

you don't need DRF at all, DRF will help you write REST servers

if you need to consume you can just use requests (http://docs.python-requests.org/en/latest/)

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/56389E08.10105%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Remco Gerlich]

Django code is just normal Python. Python can call REST APIs, sure (a nice library is Requests: docs.python-requests.org/en/latest/ )

Doing this in the view means that the user has to wait until the request ends before he gets a response. Possibly this will make the view too slow. You could also do the API requests in the background using Celery, and show the results some other way.

Remco Gerlich

[kk]

On Tuesday 03 November 2015 08:35 PM, Remco Gerlich wrote:

Django code is just normal Python. Python can call REST APIs, sure (a nice library is Requests: docs.python-requests.org/en/latest/ )

I got to see this, thanks,  had a quick look and it exactly does what I want.

Doing this in the view means that the user has to wait until the request ends before he gets a response. Possibly this will make the view too slow. You could also do the API requests in the background using Celery, and show the results some other way.

What do you mean doing it in the background?

How could it enhance the performance?
happy hacking.
Krishnakant.

Remco Gerlich

On Tue, Nov 3, 2015 at 12:44 PM, kk <krm...@gmail.com> wrote:

Dear all,
I wish to know if I need to do some thing special for consuming a RESTfull server from some other provider?
What should I do in the views?
Do I need the complete DRF to do this?
Can I do this with just Django's views and then send data across to templates?
I mean, can I write views to connect and call the API, send and receive data and then send the output to the templates?
The encoding is in json when interacting with the remote REST API.
happy hacking.
Krishnakant.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/56389E08.10105%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFAGLK1rzNjgB2XxckRkZJqgOppwS6CiMxxwMd%2BmChnvKuy1Lw%40mail.gmail.com.

[Gergely Polonkai]

On 4 Nov 2015 05:45, "kk" <krm...@gmail.com> wrote:
>
>
>
> On Tuesday 03 November 2015 08:35 PM, Remco Gerlich wrote:
>>
>> Django code is just normal Python. Python can call REST APIs, sure (a nice library is Requests: docs.python-requests.org/en/latest/ )
>>
> I got to see this, thanks,  had a quick look and it exactly does what I want.
>
>
>> Doing this in the view means that the user has to wait until the request ends before he gets a response. Possibly this will make the view too slow. You could also do the API requests in the background using Celery, and show the results some other way.
>
>
> What do you mean doing it in the background?
> How could it enhance the performance?

Imagine a slow web service that you consume (ie. a weather service that is used by so many people).

Now when your user downloads the page that displays the service's data, they have to wait, because it takes a long time for your app to get the result from the service.

With the suggested solution, there is a background task that runs on your server every 15 minutes or so. It fetches the data from the service and stores it in your database. Now when a user wants to see your page, Django gets the values from its own database, so the user doesn't have to wait for your app to get it from the server.

As you can see, the tradeoff here is disk usage: you have to store the service's data on your machine. Also, if the data you fetch changes quickly (like in the stock market) this solution is not so good. In this case you may want to fetch the service's data from the generated page, e.g. with AJAX calls.

Best,
Gergely

> To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/56398D36.1080903%40gmail.com.

[kk]

Ok one question,
I would like to store a client connection in some kind of a global place for my entire Django frontend.
So that the request object can be used from any view.
Can you sug    gest some guideline to do this?
Happy hacking.
Krishnakant.

On Tuesday 03 November 2015 08:35 PM, Remco Gerlich wrote:

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFAGLK1rzNjgB2XxckRkZJqgOppwS6CiMxxwMd%2BmChnvKuy1Lw%40mail.gmail.com.

[Gergely Polonkai]

On 4 Nov 2015 17:31, "kk" <krm...@gmail.com> wrote:
>
>
> Ok one question,
> I would like to store a client connection in some kind of a global place for my entire Django frontend.
> So that the request object can be used from any view.
> Can you sug    gest some guideline to do this?
> Happy hacking.
> Krishnakant.

That *may* work in your development server, but not in production. Most production environments run instances on a per-request basis, so the global connection you open for connection A will most probably be closed when the connection B arrives.

> To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/563A32E4.1050105%40gmail.com.

[Avraham Serour]

the question is why, why would you want to store a global connection for a REST server?

keep in mind that you would be making HTTP requests, meaning even that you had a global variable holding the connection it would just open and close each tie you make a request.

if you need t keep a connection open than maybe you don't need a REST server but something else.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CACczBUK%2BdYHCQbBgR%3DHWfKqihL3LPPRFTAQRFz8%3Djgk6UTQkcg%40mail.gmail.com.

[kk]

On Wednesday 04 November 2015 10:43 PM, Avraham Serour wrote:
> the question is why, why would you want to store a global connection
> for a REST server?
> keep in mind that you would be making HTTP requests, meaning even that
> you had a global variable holding the connection it would just open
> and close each tie you make a request.

No, I am not talking about the REST server.
The REST server is a totally different service and I am just consuming
it through Django views.
So I have to use a client connection object such as Python request
So I want to keep it as global, so that all views can access it from a
single location, instead of creating a client request instance for every
view on every call.


Happy hacking.
Krishnakant.

[marcin....@gmail.com]

Just cache the result and call remote when cache is timed out / invalidated. 

Or load remote data using separate view, as a proxy, and call it from js, for example. 

Or do both.

 

Do not rely on sharing any instances between threads/processes. Views should be stateless.

  

BR,

Marcin.

[Jani Tiainen]

Well your workflow would be following steps roughly:

1) End user requests URL from your Django site

2) Django router URL to a view

3) View code opens remote connection to RESTful service somewhere on the web

4) View code receive response from service

5) Data is processed

6) Data is rendered to end user

Now there is problem in step 3 and 4. That part may take long time (minutes), what happens if service is down? Request will fail. Now what happens at end user part? Browser will be waiting for response. Which in turn connects to a frontend webserver which actually blocks either thread or process. Now you hit second problem, what if you run for example 20 threads/processes in total. What happens when 21st request is coming in? Well end user can't access your site at all because it's waiting for 20 older responses to come up.

That's why other people are suggesting that you don't request restful service (unless you really can guarantee that it's fast) from view code but do processing outside your web app. Like using background task to retrieve data in timely manner and store it locally, or actually read that data directly from the restful service without involving a django view.

If you could describe more of your use case, what data, what nature, why you want to access it from a view we could give you a more specific help.

Krishnakant.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/563AB16E.9060604%40gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Jani Tiainen

- Well planned is half done, and a half done has been sufficient before...