Show defensive coding: "I use wp_remote_get with a timeout, check is_wp_error and the status code, cache successful responses in a transient, and fall back to stale cached data if the API fails."
Use wp_remote_get()/wp_remote_post() for HTTP requests — never use file_get_contents or raw cURL in WordPress. Check responses with wp_remote_retrieve_response_code() and wp_remote_retrieve_body(). Cache responses with transients to avoid repeated API calls. Handle failures: check is_wp_error(), implement exponential backoff for retries, show cached stale data when the API is down, and log errors for monitoring. Strong candidates discuss: setting appropriate timeouts, sanitising API response data before use, using wp_safe_remote_get() for user-supplied URLs, and the pre_http_request filter for mocking in tests.
Senior integration question. Candidates who use file_get_contents for HTTP requests are ignoring the WordPress HTTP API and its benefits (consistent SSL handling, proxy support, transport abstraction). Those who cache responses and handle failures gracefully build reliable integrations.