Networking And Restful Apis practice questions

Convert the entire JSON to a string then split

Why it fails: Splitting a string still materialises the whole payload plus copies, consuming more memory than the original. It tempts as a way to avoid parsing overhead, but it is the correct choice only for small, already-loaded strings where no streaming parser is available.

Use the 'json.loads()' method on the full response

Why it fails: json.loads() builds the complete Python object graph in memory, so peak usage scales with the entire list. It tempts because it is the standard, convenient API, and would be correct for modest payloads where full random access is needed.

Use a custom regex to parse the JSON

Why it fails: Regex cannot reliably parse JSON's nested structures, escapes and types, and the pattern itself plus intermediate matches add memory. It tempts when only one field is needed, but a streaming parser such as ijson handles that correctly without loading everything.

requests.post(url, data=data, auth=('user', 'pass')).json()

Why it fails: Using the data parameter with a dictionary sends the data as form-encoded (application/x-www-form-urlencoded) rather than JSON. The server expects JSON, so the Content-Type header would be incorrect. The json parameter should be used to serialize the data and set the appropriate Content-Type.

requests.post(url, json=data, auth=('user', 'pass'), headers={'Accept': 'application/json'}).text

Why it fails: Although this sets the Accept header to request JSON, it uses .text to retrieve the response, which returns the raw string instead of parsing the JSON into a Python dictionary. The requirement is to automatically parse the JSON response, so .json() should be used instead of .text.

requests.post(url, data=json.dumps(data), headers={'Authorization': 'Basic user:pass'}).json()

Why it fails: This manually constructs the Authorization header and serializes data. While it may work if the credentials are base64-encoded, the header value 'Basic user:pass' is incorrect because it lacks base64 encoding. The auth parameter is the correct way to handle Basic Auth, and using json parameter is simpler for JSON payloads.

requests.get('https://api.example.com/items', data={'category': 'books', 'limit': 10})

Why it fails: The 'data' argument is used to send form-encoded data in the request body, typically for POST requests. When used with GET, 'requests' will still send a body, but many servers ignore it or reject it. Query parameters should be passed via 'params', not 'data', to ensure they are appended to the URL as expected by the API.

requests.get('https://api.example.com/items', json={'category': 'books', 'limit': 10})

Why it fails: The 'json' argument serializes the dictionary to JSON and sends it in the request body with the 'Content-Type: application/json' header. This is meant for POST, PUT, or PATCH requests, not for GET query parameters. Using 'json' with GET will not append the parameters to the URL, so the server will not receive them as query filters.

requests.get('https://api.example.com/items?category=books&limit=10')

Why it fails: While manually constructing the query string in the URL works, it is error-prone because you must handle URL encoding yourself. If the parameter values contain special characters like spaces or ampersands, the URL could break. The 'params' argument is preferred for safety and readability. However, in this specific case, the manual URL is technically valid, but the question asks for the correct snippet, and the idiomatic approach uses 'params'.

Use requests.get() with the timeout parameter set to the value of Retry-After, and catch requests.exceptions.Timeout to trigger a retry.

Why it fails: The timeout parameter controls how long the client waits for a response, not how long to pause before retrying. Setting timeout to the Retry-After value does not delay the retry; it may cause the request to time out prematurely. This does not implement the required wait-and-retry logic and would not honor the server's requested delay.

Configure a requests.Session() with an HTTPAdapter that has max_retries set to 3, and rely on urllib3's built-in handling of Retry-After for 429 responses.

Why it fails: While urllib3's Retry class can handle Retry-After for certain status codes, by default it does not retry on 429 unless explicitly configured with status_forcelist or respect_retry_after_header. Simply setting max_retries to 3 does not automatically honor the Retry-After header for 429 responses. This approach may not meet the requirement without additional custom configuration.

Use a try/except block around requests.get(), and in the except clause call time.sleep(5) before retrying, ignoring the Retry-After header.

Why it fails: This approach uses a fixed delay of 5 seconds and ignores the Retry-After header, which may be longer or shorter than the server's requirement. If the server asks for 30 seconds, retrying after 5 seconds will likely result in another 429 response and may worsen rate limiting. The scenario explicitly requires honoring the server-specified interval, so ignoring the header fails.

Access response.json()['items'] directly and catch a KeyError to set a flag.

Why it fails: Direct dictionary access with ['items'] raises a KeyError when the key is absent. While catching the exception can set a flag, this approach is more error-prone and less readable than using .get(). It also does not inherently distinguish between missing and present-but-empty without additional logic. The requirement is to handle the response without raising an exception, and this method relies on exception handling, which is unnecessary here.

Use response.json().get('items') and then check if the result is None.

Why it fails: Calling .get('items') without a default returns None when the key is missing. This avoids a KeyError, but it does not provide a safe fallback for downstream processing. If the key is missing, the result is None, which may cause issues if the code expects a list. The scenario requires handling the response without exception, which this does, but it does not offer the same robustness as providing a default empty list.

Check if 'items' in response.json() and then access it, else use None.

Why it fails: Using the 'in' operator checks for key presence and avoids a KeyError, but it returns None when the key is missing. The scenario expects to handle the response without exception, which this does, but it does not provide a default empty list. If the calling code expects a list, this could lead to a TypeError later. The .get() method with a default is more robust and idiomatic for this use case.

Check if response.ok is False and then log the error.

Why it fails: 'response.ok' is True for status codes less than 400, so it would be False for a 500. Checking it and logging is a start, but it does not catch exceptions that occur before a response is received, such as connection errors or timeouts. Without a try-except block, those exceptions would propagate and crash the script, violating the requirement to handle errors gracefully.

Use requests.get() with a timeout and ignore any exceptions.

Why it fails: Setting a timeout is good practice to prevent hanging, but ignoring exceptions means you will not log the error or status code, and the script may continue with invalid data. The scenario explicitly requires logging the status code and not crashing, so silently ignoring exceptions fails to meet the requirement. You need to catch and handle exceptions appropriately.

Call response.raise_for_status() and catch requests.exceptions.HTTPError.

Why it fails: 'raise_for_status()' raises an 'HTTPError' for 4xx and 5xx responses, which you can catch. However, this approach does not handle network exceptions like timeouts or connection errors, which would still crash the script. The scenario requires handling all errors gracefully, including the 500, and logging the status code. While 'raise_for_status()' is useful, it alone is insufficient for robust error handling.

Use the 'files' parameter with a file object opened in binary mode to requests.post().

Why it fails: Using the 'files' parameter with a file object will indeed stream the file in a multipart/form-data request, but it still reads the file in chunks and may not be as memory-efficient as using a generator. However, the 'files' parameter is the standard way to upload files with requests. The question specifies streaming to avoid high memory usage; while 'files' does stream, it is not the most memory-efficient for very large files because it may still buffer. The better answer is to use a generator with the 'data' parameter.

Set the 'stream' parameter to True in requests.post() and pass the file object as 'data'.

Why it fails: The 'stream' parameter in requests controls whether the response is streamed, not the request. Setting 'stream=True' affects how the response body is downloaded, not how the request body is sent. Passing a file object as 'data' will still read the entire file into memory. To stream the request, you must provide an iterable or generator as the 'data' parameter. This option misunderstands the purpose of the 'stream' parameter.

Pass a file object opened in binary mode as the 'data' parameter to requests.post().

Why it fails: Passing a file object as the 'data' parameter will cause requests to read the entire file into memory before sending it, which defeats the purpose of streaming. The 'data' parameter is intended for form-encoded data, not for large file uploads. To stream a file, you should use the 'files' parameter or provide a generator. This approach would not meet the requirement of low memory usage.

Use response.json() without checking the status code, because it will raise an exception if the response is not valid JSON.

Why it fails: While response.json() raises a JSONDecodeError if the body is not valid JSON, it does not check the HTTP status code. A 404 or 500 response might still contain valid JSON (e.g., an error object), and calling response.json() would succeed, potentially masking the error. It is better to check the status code or use raise_for_status() before parsing JSON.

Use response.ok to determine if the request was successful, and if not, access response.content to get the error message.

Why it fails: response.ok is True for status codes less than 400, which is a quick check, but it does not provide details about the error. Accessing response.content gives raw bytes, not a parsed error message. While you could decode it, this is not a robust practice compared to using raise_for_status() or checking status_code and parsing JSON. The scenario asks for correct practices, and this is less precise.

Rely on the default behavior of requests, which automatically raises an exception for any non-2xx response.

Why it fails: By default, requests does not raise exceptions for non-2xx status codes; it simply returns the response object. You must call raise_for_status() or check the status code manually. Assuming automatic exception raising is a common misconception and would lead to unhandled errors in the client.

Use 'requests.get()' with 'allow_redirects=False' and manually handle each redirect by inspecting the 'Location' header and re-sending the request with the Authorization header.

Why it fails: Disabling redirects and manually handling them gives full control but is not the recommended approach for a client that must follow redirects automatically. It requires implementing redirect logic, which is error-prone. The scenario expects the client to handle redirects, and while this method can preserve the Authorization header, it is not one of the two correct approaches because it bypasses the library's built-in redirect handling and is less efficient.

Set the 'Authorization' header directly on the request and rely on requests to automatically forward it on redirects to the same host.

Why it fails: Setting the header directly works for the initial request, but requests will not forward the Authorization header on redirects to a different host by default. Since the API may redirect to a different host for authentication, this approach would fail. It is not a reliable way to handle authentication across redirects, especially when hosts differ. Therefore, it is not one of the correct approaches.

Use a 'requests.Session' and set 'session.max_redirects' to a high value, then set the 'Authorization' header on the session.

Why it fails: Setting the Authorization header on the session applies it to all requests made with that session, but requests still strips the header on redirects to a different host. Increasing 'max_redirects' only controls how many redirects are followed, not header preservation. This approach does not solve the problem of losing the Authorization header on cross-host redirects, so it is incorrect.

data = response.json(); name = data.user.name

Why it fails: `response.json()` returns a dictionary, not an object with attributes. In Python, dictionaries do not support attribute-style access (e.g., `data.user`). While some libraries like `SimpleNamespace` allow attribute access, the standard `requests` JSON parsing returns plain dicts. Attempting `data.user` would raise an `AttributeError`.

data = response.json(); name = data['user'].name

Why it fails: This mixes dictionary and attribute access. `data['user']` returns a dictionary, and then `.name` attempts attribute access on that dictionary, which will fail with an `AttributeError`. To access a key in a dictionary, you must use square brackets, like `['name']`. Therefore, this option is incorrect.

data = json.loads(response.text); name = data['user']['name']

Why it fails: While `json.loads(response.text)` can work, it is not the idiomatic way with `requests`. The `response.json()` method is preferred because it automatically handles the decoding and provides better error messages. However, the primary issue is that this option is not the best practice; it's redundant and less efficient. The correct answer uses `response.json()` directly.

requests.post(url, data=json.dumps({'key': 'value'}), headers={'Content-Type': 'application/json'})

Why it fails: While this approach manually serializes the data and sets the header, it is more verbose and error-prone. The `json` parameter is preferred because it handles serialization and headers automatically. However, this method can work if done correctly, but it's not the best practice. The question asks for the correct snippet, and the `json` parameter is the recommended one.

requests.post(url, params={'key': 'value'})

Why it fails: The `params` parameter is used to append query parameters to the URL, not to send a request body. This would result in a GET-style query string appended to the URL, and the POST request would have an empty body. This is incorrect for sending a JSON payload.

requests.post(url, data={'key': 'value'})

Why it fails: Using `data` with a dictionary sends the data as form-encoded (`application/x-www-form-urlencoded`), not JSON. The `Content-Type` header will be set to `application/x-www-form-urlencoded`, which is not what the API expects. This would likely cause the server to reject the request or misinterpret the payload.

UDP datagram sockets

Why it fails: SOCK_STREAM denotes connection-oriented TCP byte streams, not UDP's connectionless datagrams, which use SOCK_DGRAM. It is tempting because UDP is a common transport alternative, and SOCK_DGRAM would be the right constant when a scenario needs unreliable, message-boundary-preserving datagram delivery rather than a sequenced stream.

Raw network sockets

Why it fails: Raw sockets, bypassing transport-layer processing, are created with SOCK_RAW, not SOCK_STREAM, which requests TCP's sequenced, connection-oriented byte stream. It is tempting because raw sockets also use the socket API, and SOCK_RAW would be correct when a scenario requires crafting packets with custom headers.

Unix domain sockets only

Why it fails: SOCK_STREAM denotes a reliable, connection-oriented byte stream, typically TCP, and is not restricted to Unix domain sockets; AF_UNIX is the address family that selects Unix domain sockets. It tempts because Unix domain sockets can use SOCK_STREAM, and would be correct when pairing it with AF_UNIX.

sock.bind(('192.168.1.50', 8080))

Why it fails: bind() assigns a local address and port to the socket; on a client it would attempt to claim 192.168.1.50 locally, which is the remote server's address. It is tempting because it precedes connect() in server code, but clients normally let the OS choose the ephemeral source port.

sock.accept()

Why it fails: accept() blocks on a listening socket to return a new connected socket for an inbound client; calling it on an unconnected client socket raises an error. It is tempting because it is the server-side counterpart to connect(), used after bind() and listen() when writing the accepting peer.

sock.listen(1)

Why it fails: listen() transitions a bound socket into a passive server state that queues incoming connections; a client socket never calls it. It is tempting because it appears in the canonical TCP server sequence alongside connect(), but it belongs to the server side, not the connecting client.

Wrap the access in a try-except KeyError block

Why it fails: Catching KeyError works but wraps every lookup in exception handling, whereas dict.get() returns None for a missing key without raising. try-except suits cases where the key's absence signals a genuine error needing distinct recovery, not routine optional-field reads.

Check 'if 'key' in response.json():' before access

Why it fails: Calling response.json() again re-parses the body and, on many response objects, raises because the stream is already consumed; the parsed dictionary should be stored once and checked with 'key' in data. It is tempting because membership testing is the Pythonic guard, but it must run against the parsed object.

Use response.json()['key'] and assume the API schema is always correct

Why it fails: Direct subscripting raises KeyError the moment a nested key is absent, so a schema drift or partial payload crashes the call. It is tempting because bracket access is the obvious way to read a known field, and it is correct when the API contract is guaranteed and validated upstream.

It sets the send buffer size to 5.0 bytes

Why it fails: settimeout() sets a timeout on blocking socket operations, raising socket.timeout after 5.0 seconds; it never touches buffer sizes. Buffer sizing is handled by setsockopt with SO_SNDBUF, so the numeric argument and socket-object receiver make this distractor look plausible.

It blocks the thread for exactly 5 seconds

Why it fails: settimeout() bounds how long a blocking call such as recv or accept waits before raising socket.timeout; it does not sleep or block unconditionally. time.sleep(5.0) blocks a thread for exactly five seconds, which is the behaviour this option mistakenly attributes to sockets.

It forces the socket to close after 5 seconds of inactivity

Why it fails: settimeout() makes blocking calls raise socket.timeout once the interval elapses; the socket stays open and reusable. Idle-connection teardown is a server-side policy, often implemented with SO_KEEPALIVE or application timers, so a timeout value of 5 seconds looks like an inactivity limit.

POST

Why it fails: POST submits data to a URI for processing, typically creating a subordinate resource or triggering an action, and is neither safe nor idempotent. PUT replaces the resource at a known URI, which is the update operation. POST fits creating new resources.

GET

Why it fails: GET is a safe, idempotent method that retrieves a representation without altering server state. PUT submits a replacement representation to the resource URI, performing the update. GET is correct when the task is reading or fetching a resource rather than modifying it.

DELETE

Why it fails: DELETE removes the identified resource; it does not modify an existing representation. PUT sends a complete replacement representation to the target URI, which is the update operation. DELETE is correct when the requirement is to remove a resource, such as cleaning up a record.

Switch to a different base URL immediately

Why it fails: Switching base URL abandons the throttled endpoint rather than honouring the 429 response, which signals rate limiting, not endpoint failure. It is tempting as a failover tactic, and would be correct for a 503 or regional outage, where redirecting to a healthy host is the intended remedy.

Ignore 429 errors and continue execution

Why it fails: The request will continue to fail, leading to data loss.

Retry immediately in a loop until successful

Why it fails: Retrying immediately in a loop ignores the Retry-After header and the need for exponential backoff, amplifying load and prolonging throttling. It is tempting because it is trivial to code, and would work only where the server imposes no rate limit and failures are transient network blips.

A tuple of values

Why it fails: A tuple of values supplies no parameter names, so requests cannot construct the 'name=value' pairs a query string requires. Tuples appear legitimately as the inner elements of a list of two-tuples for repeated keys; a bare tuple of values alone carries no mapping and fails encoding.

A single formatted string

Why it fails: Passing a pre-formatted string bypasses requests' own encoding, so reserved characters in values are not percent-escaped and duplicate keys cannot be represented. The params argument exists to accept a dictionary or list of two-tuples, which requests serialises correctly; a raw string suits only when you have already encoded the query yourself.

A list of strings

Why it fails: A flat list of strings gives requests no key/value pairing, so it cannot build 'key=value' pairs and raises a TypeError during encoding. Lists of two-tuples are the accepted form for repeated parameters; a plain list of strings would only make sense if the library treated each element as a complete pair, which it does not.

Wrap the session object in a threading.Lock

Why it fails: A Lock serialises every request through one session, destroying the concurrency threading was introduced to provide. It is tempting because shared mutable state normally needs locking, but requests.Session is designed for concurrent use; the correct pattern is one session per thread, avoiding cross-thread contention.

Share a single global Session object across all threads

Why it fails: A Session is not thread-safe; sharing one globally across threads risks corrupted connection-pool state and interleaved cookie handling. It is tempting because a single session maximises connection reuse, and would be correct in single-threaded code or when each thread creates its own Session instance.

Disable connection pooling using 'pool_connections=0'

Why it fails: Setting pool_connections=0 removes connection reuse entirely, forcing a fresh TCP and TLS handshake per request and defeating the purpose of session persistence. It is tempting as a crude way to avoid cross-thread pool contention, and would be correct only if pooling itself caused the fault being diagnosed.

Use the 'data' argument

Why it fails: The 'data' argument supplies the request body for methods such as POST, not headers. It is tempting because both are request components, but headers belong in the separate 'headers' dictionary, which is the correct choice when adding custom HTTP headers to a GET request.

Pass it as part of the URL string

Why it fails: Headers are transmitted as separate HTTP message fields, not URL components; embedding them in the URL string produces an invalid request target. It is tempting because query strings also carry metadata, but they populate 'params', not the header section of the request.

Use the 'params' dictionary

Why it fails: The 'params' dictionary appends query-string parameters to the URL, not HTTP headers. It is tempting because both are dictionaries passed to 'requests.get()', but headers require the dedicated 'headers' argument, which is the correct choice for custom HTTP headers.