They 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 <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.

• requests.request(method, url, **kwargs)

  It says "Constructs and sends a Request.". So this one is for ANY type of request, and you need to pass in 2 required arguments: the method and the URL. All the possible kwargs are listed in the doc, including the params from your example.

• requests.get(url, params=None, **kwargs)

  It says "Sends a GET request.". So this one is more specific in that it is only for a GET request. It only has 1 required argument, the URL. No need to pass "GET". And then kwargs is "Optional arguments that request takes." which just points back to the main requests.request method.

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:

• GET /api/v1/user/[user-id]
• PATCH /api/v1/user/[user-id]
• DELETE /api/v1/user/[user-id]

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/{user_id}"
    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.

Python 3:

import urllib.request
contents = urllib.request.urlopen("http://example.com/foo/bar").read()

Python 2:

import urllib2
contents = urllib2.urlopen("http://example.com/foo/bar").read()

Documentation for urllib.request and read.