Full Stack Interview Q&A: HTTP Errors, Authentication and Safe Retries
Answer HTTP status, authentication and retry questions with a checked JavaScript client example.
1. How do you explain an API failure to a user?
Separate the technical diagnosis from the user-facing next step. A missing resource, invalid input, lost connection and temporary server failure need different handling. Display a useful message while retaining a non-sensitive request identifier for support. Never show a database stack trace, password, token or internal query in a public error panel.
2. What is the difference between 401 and 403?
401 indicates that valid authentication credentials are needed. 403 indicates refusal to fulfil the request, such as a permission restriction. Refreshing a page or signing in again does not necessarily grant access. Each server must enforce authorization regardless of whether the frontend hides a button.
3. Does fetch throw when an HTTP response is 404?
A received HTTP error response needs explicit status handling; a network failure is a different case. This example uses a minimal mock to check the classification without contacting a server. It is an illustrative client helper, not an existing AI Leaf API.
async function getCourse(fetcher) {
const response = await fetcher('/api/courses/example');
if (!response.ok) {
if (response.status === 404) return {kind: 'missing'};
if (response.status === 401) return {kind: 'sign-in'};
if (response.status === 403) return {kind: 'restricted'};
throw new Error('Request failed');
}
return {kind: 'ready', course: await response.json()};
}
const result = await getCourse(async () => ({ok: false, status: 404}));
console.log(result.kind);Expected output is missing. The JavaScript example was checked locally with Node.js. A real application also handles rejected requests, malformed response bodies, cancellation, loading states and accessibility. Do not treat this short exercise as a complete production client.
4. Should you retry every failed request?
No. A retry needs a reason and a limit. Repeating invalid input will not fix it. Repeating a payment or order creation after an uncertain response can duplicate the operation unless the server supports an appropriate idempotency mechanism. Even a read retry should have bounded attempts and a suitable delay rather than an endless loop.
5. Where should input validation happen?
The browser can provide quick feedback, but the server must independently validate the request and check permissions. Client checks can be bypassed. Validate field types, lengths and business rules; use safe database access patterns and avoid logging secrets. A submitted course identifier must not be trusted as proof that the user may read its private content.
Practice interview follow-up
Change the mock to status 403 and expect restricted. Change it to a successful response with json returning an object containing title SQL Basics: expect ready and that course title. Finally make the mock reject with a network error and show where the caller should catch it. Explain why a missing course should not become a blank screen or an automatic sign-out.
Prepared by AI Leaf Global Learn for classroom learners in Mudichur/Tambaram, Chennai, and online learners across India. Confirm current batches with the team.
Full Stack Development course.
MDN HTTP status reference.
MDN Fetch guide.