277 JavaScript Frontend Developer Interview Questions & Answers

I would define a web API as a documented interface that lets software exchange requests, responses, or events over web protocols. In this design, a JavaScript client sends an HTTP request to a remote Web API. The example uses GET /users/123, and the Fetch example calls /v1/users/${id}. Requests can include headers such as Accept and Authorization. The API returns a status code, headers, and usually JSON data. The client checks the HTTP result before using the response. Authentication identifies the caller, while trusted server-side logic controls access. Versioning such as /v1 helps preserve compatibility. This remote API is different from browser Web APIs such as DOM, Fetch, and LocalStorage.

A web API is a documented way for software systems to communicate. A JavaScript app sends a request to a remote API and receives a response. The API contract explains the endpoint, HTTP method, headers, body, data shape, status codes, and errors. In this diagram, the client calls a Web API server. The API can interact with a database or external service. It then sends the response back to the client. The browser checks that response before using its JSON data. The same contract also explains authentication, versioning, and compatibility.

• What request and response shape should the client expect?
• Which authentication mechanism should the browser use?
• Which status codes and error shapes are part of the contract?
• How should API versions remain compatible with older clients?

An endpoint is a URL for a resource or action. The diagram shows examples such as /users and /orders. Its main request example is GET /users/123. The JavaScript Fetch example uses the versioned path /v1/users/${id}.

The HTTP method tells the API which action is requested. The diagram lists GET, POST, PUT, and DELETE. GET reads data. POST creates data. PUT updates data. DELETE removes data.

Headers carry extra information about a request or response. The Fetch example sends Accept: application/json. It also sends Authorization: Bearer YOUR_TOKEN. The Authorization header carries a bearer credential used for authentication.

A body carries data sent in a request or returned in a response. The diagram says JSON is commonly used for this data. The shown GET Fetch request has no request body. Its successful response contains JSON with id, name, and email.

A schema defines the expected structure and types of request and response data. It gives the client and API a shared data contract.

The JavaScript client starts the HTTP request. The request arrow moves from the client to the Web API server.

The remote API is a separate network boundary. It can interact with its database or external services. The diagram shows this as a separate bidirectional service and data interaction.

That backend interaction is not the browser response. After the API finishes the operation, the response travels from the Web API back to the client.

The shown successful response contains 200 OK, headers, and a JSON body. The Fetch example checks res.ok before parsing the expected success data with res.json().

Fetch normally resolves when an HTTP response arrives, including many HTTP error responses. Therefore, the client must check the HTTP result. A network failure is different because Fetch can reject before a usable HTTP response is received.

A status code tells the client how the HTTP request finished. The diagram shows 200 OK as the normal success result. It also shows 404 Not Found as another possible result.

The error section includes 400, 401, and 500. A 400 response means the request was not accepted as valid. A 401 response means authentication is required or was not accepted. A 500 response means the remote API encountered a server-side failure.

The diagram says errors should use a clear format with helpful messages. The browser should not treat every response as successful data. It should check the HTTP result before parsing the body expected for success.

Authentication and authorization are different ideas. Authentication establishes who the caller is. Authorization decides what that caller may access. The browser may send a bearer token, but trusted server-side logic must enforce access decisions.

Versioning allows an API contract to evolve over time. The diagram uses /v1/users as its example.

A client written for version 1 should continue receiving the version 1 behavior it expects. This is backward compatibility. It helps older clients continue working when newer API behavior is introduced.

The main trade-off is maintenance. Keeping an older contract available reduces client breakage. However, supporting more versions can increase development, testing, and documentation work.

The Web API in the main flow is a remote HTTP API. The JavaScript application reaches it across the network using HTTP or HTTPS.

Browser Web APIs are different. They are capabilities provided by the browser environment. The diagram gives DOM, Fetch, and LocalStorage as examples.

The DOM API lets JavaScript read or change page content. Fetch provides the browser interface for making network requests. LocalStorage stores data in the browser.

Fetch is therefore a browser Web API used to call the remote Web API. The remote service and the browser capability are not the same thing.

The main frontend concerns are request count, response size, parsing work, error handling, security, and API maintenance. Larger JSON responses use more network data and browser processing. More requests can increase waiting time. Clear schemas make integration safer because both sides know the expected data shape. Error handling adds frontend code, but it stops failed responses from being treated as valid data. Authentication also creates an important security boundary. The browser can send a bearer token, but trusted server-side logic must enforce authorization. Versioning such as /v1 improves backward compatibility, but supporting older versions adds maintenance and testing work. Keeping remote HTTP APIs separate from browser Web APIs also makes responsibilities easier to understand.

I would explain HTTP as the web's application-layer request-and-response protocol. A browser can request a URL such as https://example.com/index.html with GET, and the server returns an HTTP response such as 200 OK with headers and an HTML body. HTTP is stateless, so each request is independent. Cookies can carry client state, caching can reduce repeated network work, and HTTPS protects HTTP with TLS. The trade-off is that caching improves speed but can return older content until the cache policy requires fresh data.

HTTP is the basic way a browser and a web server exchange requests and responses. The browser asks for a resource identified by a URL. The request has a method, headers, and sometimes a body. The response has a status code, headers, and usually a body. HTTP itself is stateless, so each request is independent. Cookies can carry client state. Caching can reduce repeated network work. HTTPS protects HTTP with TLS.

• How deep should I go into caching behavior beyond the headers shown in the diagram?
• Should I keep the explanation at the HTTP protocol level, or also discuss how browser code consumes HTTP responses?

The user enters https://example.com/index.html.

DNS resolves example.com to an IP address.

The browser opens a TCP connection to the server.

Because the URL uses HTTPS, TLS protects the HTTP traffic.

The browser sends GET /index.html HTTP/1.1.

The Host header identifies example.com.

The request also shows User-Agent, Accept, Accept-Language, Cookie, and Cache-Control headers.

This GET example has no request body.

The request line contains the method, path, and HTTP version.

Headers are key-value metadata about the request.

A body is optional and carries request data when the API uses one.

The response starts with a status line.

The example is HTTP/1.1 200 OK.

The response headers include Content-Type, Content-Length, Cache-Control, and Set-Cookie.

The response body contains the returned representation.

In the diagram, that representation is HTML.

The browser sends the request through the Internet.

The request reaches a web server, such as Nginx.

The web server communicates with the origin server shown as the application and database boundary.

The response travels back toward the browser.

The browser receives 200 OK with headers and HTML.

It can then make more requests for CSS, JavaScript, and images.

Finally, the browser renders the page.

HTTP is stateless during this flow.

That means each request is independent of earlier requests.

Methods describe the requested action.

The diagram shows GET for read, POST for create, PUT for replace, PATCH for partial update, and DELETE for remove.

It also shows HEAD, which is like GET but without a response body.

Status codes describe the result.

1xx is informational.

2xx is success.

3xx is redirection.

4xx is a client error.

5xx is a server error.

The walkthrough uses 200 OK as its success response.

Caching can reduce load and make repeated responses faster.

The diagram names Cache-Control, ETag, Last-Modified, and Expires as caching-related headers.

Cookies are small data items stored by the browser.

The browser can send a cookie with a request.

The response can set a cookie with Set-Cookie.

Intermediaries can sit between the browser and origin.

The diagram lists proxies, CDNs, and gateways.

They can forward, cache, compress, or filter requests and responses.

HTTPS means HTTP over TLS.

TLS encrypts data, verifies the server, and protects privacy and integrity in transit.

HTTP is the application-layer protocol for web requests and responses.

JSON is a text data format that can be carried in an HTTP body.

REST is an architectural style that commonly uses HTTP methods and URLs to design APIs.

Using HTTP does not automatically make an API RESTful.

TCP is a transport-layer protocol that provides reliable delivery for HTTP.

For HTTPS in this diagram, HTTP runs over TLS, with TCP underneath.

HTTP design choices mainly affect network work, freshness, state, and security. Caching can make repeated loads faster and reduce traffic, but cached content can become old. Cookies can carry browser state, but they add state to later requests. Intermediaries such as proxies, CDNs, and gateways can improve delivery, but they add more components to the path. HTTPS adds TLS protection for data in transit. The browser still needs to understand status codes and response headers before deciding what the response means.

I would explain REST as an architectural style for web APIs. A browser works with resources through URLs and standard HTTP methods. For example, it can send GET /api/users?page=2&limit=10 and receive JSON with a 200 OK response. Each request is stateless, so it carries the information needed for that request, such as authentication data. I check status codes before using the response, handle validation and errors consistently, and use pagination and HTTP caching when needed. REST is not a JavaScript library. JavaScript tools such as fetch are only clients used to call the API.

A REST API is a way for a browser and a remote API to communicate over HTTP. The browser works with resources, such as users, through URLs. It chooses an HTTP method to describe the action. The API returns a representation of the resource, usually JSON, with a status code. Each request is stateless, so the server does not keep client session state between requests. A useful REST design also gives the browser clear validation, consistent errors, pagination, authentication, and caching rules.

• Should the browser authenticate with the shown bearer token or a secure HttpOnly cookie?
• What pagination metadata should the response include?
• Which HTTP caching rules, such as Cache-Control, ETag, or Last-Modified, are supported?
• What fields should every error response contain?

The browser is the client. The REST API is the remote boundary.

For the diagram's list request, the browser sends:

GET /api/users?page=2&limit=10

The request says it accepts application/json. The diagram also shows an Authorization header containing a bearer token.

The API sends a response back to the browser. The successful example uses 200 OK and application/json. Its JSON contains data and meta fields.

The resource is users. The URL identifies that resource. The page and limit query parameters choose one page of users.

HTTP methods describe the requested operation. GET reads a resource. POST creates a resource. PUT replaces a resource. PATCH updates part of a resource. DELETE removes a resource.

GET is safe because its intended action does not change the resource. GET, PUT, and DELETE are idempotent in the shown design. Idempotent means repeating the same operation has the same intended effect as doing it once. POST is not safe or idempotent. The diagram correctly marks PATCH as not guaranteed to be idempotent.

A frontend can use the browser's fetch API to send the request.

A technically valid example matching the diagram is:

const res = await fetch('/api/users?page=2&limit=10', { headers: { 'Accept': 'application/json', 'Authorization': 'Bearer ' + token } });

The request travels from the browser to the API server. The API handles the request and returns a representation to the browser.

The request is stateless. It carries the information needed for that request, such as parameters and authentication data. The server does not depend on stored client session state from an earlier request.

The frontend should check the HTTP result before using the expected JSON.

The diagram's JavaScript checks res.ok. If res.ok is false, it creates an error containing the response status. If the response succeeds, the browser parses the body with res.json().

The server also validates input. The diagram shows 400 Bad Request for invalid input and recommends clear validation messages.

The shown status codes are:

• 200 OK for success.
• 201 Created when a resource is created.
• 400 Bad Request for invalid input.
• 401 Unauthorized when authentication is missing or fails.
• 403 Forbidden when the caller does not have permission.
• 404 Not Found when the resource is missing.
• 500 Internal Server Error for a server error.

On success, the frontend parses the JSON representation. The example then uses json.data and json.meta.

The meta value can carry pagination information. This lets the frontend understand the current result page without downloading every user.

Errors should have one consistent shape. The diagram shows an example containing an error message and a code such as INVALID_EMAIL.

Consistent errors make frontend behavior easier to predict. The client can recognize known problems instead of guessing from unrelated response formats.

A GET request can be repeated when needed because GET is safe and idempotent. That does not mean every HTTP request should be retried. POST and non-idempotent PATCH requests must not be blindly repeated.

Pagination keeps list responses manageable. The diagram uses page and limit query parameters and recommends returning pagination metadata.

Authentication identifies the caller. The request example sends a bearer token in the Authorization header. The diagram also notes secure HttpOnly cookies as another possible authentication mechanism. HTTPS protects the request while it travels across the network.

Authentication and authorization are different. Authentication establishes who the caller is. Authorization decides what that caller may do. The trusted server must enforce permission checks.

HTTP caching can reduce repeated transfers. The diagram shows Cache-Control, ETag, and Last-Modified. These HTTP mechanisms let browsers and CDNs reuse fresh responses or check whether cached data changed.

REST itself is not a JavaScript package or framework. It is an architectural style. fetch, Axios, or another HTTP client can be used to call a REST API.

The main trade-offs are easy to explain. Pagination keeps responses smaller, but the frontend must track the current page and pagination metadata. HTTP caching can make reads faster and reduce requests, but the client must follow freshness rules correctly. Authentication improves security, but bearer tokens or cookies need careful handling. Consistent status codes and error objects require some design work, but they make frontend behavior predictable. Retry safety also depends on the HTTP operation. GET can be repeated safely, while POST and a PATCH that is not idempotent should not be retried blindly.