Difference between using requests.get() and requests.session().get()?
Question:
Sometimes I see people invoke web API using requests.Session object:
client = requests.session()
resp = client.get(url='...')
But sometimes they don’t:
resp = requests.get(url='...')
Can somebody explain when should we use Session and when we don’t need them?
Answers:
To quote the documentation
The Session object allows you to persist certain parameters across requests. It also persists cookies across all requests made from the Session instance.
Under the hood, requests.get() creates a new Session object for each request made.
By creating a session object up front, you get to reuse the session; this lets you persist cookies, for example, and lets you re-use settings to be used for all connections such as headers and query parameters. To top this all off, sessions let you take advantage of connection pooling; reusing connections to the same host.
See the Sessions documentation:
The Session object allows you to persist certain parameters across requests. It also persists cookies across all requests made from the Session instance, and will use urllib3‘s connection pooling. So if you’re making several requests to the same host, the underlying TCP connection will be reused, which can result in a significant performance increase (see HTTP persistent connection).
Sometimes I see people invoke web API using requests.Session object:
client = requests.session()
resp = client.get(url='...')
But sometimes they don’t:
resp = requests.get(url='...')
Can somebody explain when should we use Session and when we don’t need them?
To quote the documentation
The Session object allows you to persist certain parameters across requests. It also persists cookies across all requests made from the Session instance.
Under the hood, requests.get() creates a new Session object for each request made.
By creating a session object up front, you get to reuse the session; this lets you persist cookies, for example, and lets you re-use settings to be used for all connections such as headers and query parameters. To top this all off, sessions let you take advantage of connection pooling; reusing connections to the same host.
See the Sessions documentation:
The Session object allows you to persist certain parameters across requests. It also persists cookies across all requests made from the Session instance, and will use urllib3‘s connection pooling. So if you’re making several requests to the same host, the underlying TCP connection will be reused, which can result in a significant performance increase (see HTTP persistent connection).