I'm learning Python requests through a book I purchased. From the book and from the websites I researched, it states this is the proper way to perform a GET request.
requests.get(url, params=, args) In PyCharm it also shows the same thing. However, when I use Postman to test and look at the sample code it shows:
requests.request("GET", params=, args I'm not sure if I should use request.get or requests.request("GET",` and why choose one over the other.
28.6k 30 30 gold badges 115 115 silver badges 160 160 bronze badges asked Jun 29, 2021 at 22:42 31 1 1 gold badge 1 1 silver badge 2 2 bronze badges They are the same. Check the requests docs: docs.python-requests.org/en/master/api/#requests.request Commented Jun 29, 2021 at 22:45Note that requests isn't a standard Python library. With third party libraries, always check the documentation, the page @GinoMempin references has it all. requests.get is effectively shorthand for a .request() call with 'GET' and as the documentation mentions, its **kwargs are passed on to a .request() call.
Commented Jun 29, 2021 at 23:03 Always check the docs, third party library or not. Commented Jun 30, 2021 at 7:43They are both correct and will work the same.
The best way to clear up this confusion is to look at the requests source code.
Here is the code for request.get (as of 2.25.1):
def get(url, params=None, **kwargs): r"""Sends a GET request. :param url: URL for the new :class:`Request` object. :param params: (optional) Dictionary, list of tuples or bytes to send in the query string for the :class:`Request`. :param \*\*kwargs: Optional arguments that ``request`` takes. :return: :class:`Response ` object :rtype: requests.Response """ kwargs.setdefault('allow_redirects', True) return request('get', url, params=params, **kwargs) . which shows that requests.get just calls requests.request with a hardcoded 'get' for the 1st argument. All the other parameters ( url , params , **kwargs ) are all just passed through.
Basically, it is just a convenience method or a shorthand or a shortcut so you don't have to manually remember which string to pass for the method parameter. It's easier especially when using an IDE because your IDE's IntelliSense can help you select .get or .post or .delete , etc. but not the raw strings "GET" , "POST" , or "DELETE" , etc.
The requests docs can also offer some clarity.
I would say it's a matter of opinion and coding style which one to use. A use-case where it makes sense to prefer requests.request is when wrapping different API calls and providing a Python interface for them.
For example, I have these APIs:
When implementing get_user and update_user and delete_user , I could just call the .get , .post , .delete , etc. methods. But if calling these APIs required passing in many and/or complicated kwargs ( headers , auth , timeout , etc.), then that would lead to a lot of duplicated code.
Instead, you can do it all in one method then use requests.request :
def get_user(user_id): return call_api("GET", user_id) def update_user(user_id, user): return call_api("PATCH", user_id, user=user) def delete_user(user_id): return call_api("DELETE", user_id) def call_api(method, user_id, user=None): # Lots of preparation code to make a request headers = < "header1": "value1", "header2": "value2", # There can be lots of headers. "headerN": "valueN", >timeout = (1, 30) payload = user.json() if user else <> url = f"/api/v1/user/" return requests.request( method, url, headers=headers, timeout=timeout, json=payload, ) There are probably other ways to refactor the code above to reduce duplication. That's just an example, where if you called .get , .patch , .delete directly, then you might end up repeating listing all those headers every time, setting up the URL, doing validations, etc.