01: 12 Web basics every Java web developer must know – Part 1

Q1. HTTP is a stateless protocol, so how do you maintain state? How do you store user data between requests?
A1. This is a commonly asked interview question. The “http protocol is a stateless request/response based protocol”. You can retain the state information between different page requests as follows:

HTTP Session. A session identifies the requests that originate from the same browser during the period of conversation. All the servlets can share the same session. The JSESSIONID is generated by the server and can be passed to client through cookies, URL re-writing (if cookies are turned off) or built-in SSL mechanism. Care should be taken to minimize size of objects stored in session and objects stored in session should be serializable. In a Java servlet the session can be obtained as follows:

Web basics

Web basics

Q. Session tracking uses cookies by default. What would you do if the cookies are turned off?
A. If cookies are turned off, you can still enable session tracking using URL rewriting. This involves including the session ID within the link as the name/value pair as shown below.

Adding session ID to each and every link is cumbersome and hence is simplified by the following methods:

to associate a session ID with a given URL and if you are using redirection then:

When you invoke the method encodeURL(givenURL) with the cookies turned on, then session ID is not appended to the URL. Now turn the cookies off and restart the browser. If you invoke the encodeURL(givenURL) with the cookies turned off, the session ID is automatically added to the URL

Hidden Fields on the pages can maintain state and they are not visible on the browser. The server treats both hidden and non-hidden fields the same way.

The disadvantage of hidden fields is that they may expose sensitive or private information to others.

URL re-writing will append the state information as a query string to the URL. This should not be used to maintain private or sensitive information.

Cookies: A cookie is a piece of text that a Web server can store on a user’s hard disk. Cookies allow a website to store information on a user’s machine and later retrieve it. These pieces of information are stored as name-value pairs. The cookie data moves in the following manner:

– If you type the URL of a website into your browser, your browser sends the request to the Web server. When the browser does this it looks on your machine for a cookie file that URL has set. If it finds it, your browser will send all of the name-value pairs along with the URL. If it does not find a cookie file, it sends no cookie data.

– The URL’s Web server receives the cookie data and requests for a page. If name-value pairs are received, the server can use them. If no name-value pairs are received, the server can create a new ID and then sends name-value pairs to your machine in the header for the Web page it sends. Your machine stores the name value pairs on your hard disk.

Cookies can be used to determine how many visitors visit your site. It can also determine how many are new versus repeated visitors. The way it does this is by using a database. The first time a visitor arrives; the site creates a new ID in the database and sends the ID as a cookie. The next time the same user comes back, the site can increment a counter associated with that ID in the database and know how many times that visitor returns. The sites can also store user preferences so that site can look different for each visitor.

Q2. Are states bad? if yes, why?
A2. State isn’t bad, it’s a necessity. But favor stateless architecture for the number of reasons described below.

— You should ALWAYS make your systems not only as simple as possible, but also as scalable as possible. In a clustered or load balanced environment with multiple servers, maintaining of states requires the user to always return to the same server using sticky sessions or else the whole system breaks down. The answer to this problem is using sticky sessions which force the load balancer to send traffic for a given user to the same server every time. The LB is hardly balancing load if it can’t decide who gets the traffic. There are other more complicated methods for sharing sessions across multiple servers via true clustering, but getting this right is more complicated and time consuming.

State can also be problematic from a security point of view due to sharing the state between the client and server. There are methods around this problem using encryption and other techniques, but again can complicate your solution.

— The single page RIA (i.e. Rich Internet Application) making a number of RESTFul web services via AJAX requests is a very popular architecture. Making server side RESTful web services stateless is a central tenant of REST. A truly stateless RESTful web service is not only incredibly flexible and scalable thing, but also takes responsibility for handling security and deciding who can access what in the system. Since there is very little “under the covers stuff” happening to try to make this stuff “easier”, you are free to implement security however makes sense for your system.

Q3. What is the structure of an HTTP request and response?
A3. HTTP a stateless protocol, and communication between a host and a client occurs, via a request/response pair. The client initiates an HTTP request message, which is serviced through a HTTP response message in return.

HTTP Request and Response

HTTP Request and Response

Q4. What is your understanding of HTTP URLs, HTTP Verbs, and HTTP status codes?
A4 The heart of web communications is the request message, which are sent via Uniform Resource Locators (URLs).



URLs reveal the identity of the particular host with which we want to communicate, but the action that should be performed on the host is specified via HTTP verbs. A client can perform a number of actions like GET (fetch an existing resource), POST (create a new resource), PUT (update an existing resource,), DELETE (delete an existing resource), etc.

With URLs and verbs, the client can initiate requests to the server. In return, the server responds with status codes and message payloads. The status code is important and tells the client how to interpret the server response. The most common code is 200 OK, which tells the client that the request was successfully processed.

3xx: like 301, 302, etc indicate redirection, which requires the client to take additional action. The most common use-case is to jump to a different URL in order to fetch the resource.

4xx: like 404. etc means Client Error. These codes are used when the server thinks that the client is at fault, either by requesting an invalid resource or making a bad request.

5xx: like 501, 503, etc means Server Error. This class of codes are used to indicate a server failure while processing the request. The most commonly used error code is 500 Internal Server Error.

Q5. What is your understanding of the following terms … forward, redirect (aka sendRedirect), and post-back?


— a forward or include is performed internally by the servlet on the server side.
— The browser is completely unaware that it has taken place, so its original URL remains intact.
— You can set request attributes from the forwarding request (e.g. Servlet) to the resource to which it is forwarded (e.g. another Servlet or JSP).

forward, redirect and postback

forward, redirect and postback


— A redirect is a two step process, where the web application instructs the browser to fetch a second URL, which differs from the original.
— A browser reload of the second URL will not repeat the original request, but will rather fetch the second URL. This makes the second resource link book markable.
— A redirect can be marginally slower than a forward as it requires two browser requests as opposed to one with the forward.
— Any attributes placed in the original request scope are not available to the second request, since it is a new request.


— The HTTP verb POST is used to send data to the server in the body, with XML, JSON, or form fields.
— The term “back” really means that you retrieved the page initially with a GET verb to show user the <form> elements, and at the end you’re sending data back. So, a PostBack is a POST request for a page that is not the first request.

Q6. What exactly is an AJAX request?
A6. AJAX is a browser (i.e. client side) technology, which stands for Asynchronous Javascript And XML, and an AJAX call is an asynchronous request initiated by the browser that does not directly result in a page transition. An AJAX request is sometimes called an XHR request or “XmlHttpRequest”, which is the name most browsers give the object used to send an AJAX request send/receive XML, JSON, plain text or HTML. So, the “X”, AJAX was coined to send and receive XML messages asynchrously, but it can send/recive JSON, plain text, etc.

Conventional web application trasmit information to and from the sever using synchronous requests. This means you fill out a form, hit submit, and get directed to a new page with new information from the server. With AJAX when submit is pressed, JavaScript will make a request to the server, interpret the results and update the current screen. In the purest sense, the user would never know that anything was even transmitted to the server. So, AJAX is Data-driven as opposed to the conventional page-driven approach.

The modern Rich Internet Applications (RIA) use the design concept of “single page web design“, where a single rich page makes AJAX based service calls to render different sections of a page instead of the traditional approach of loading a new page of each user action. The “single page web design” can make use of client side and server side technologies.

Q07 to Q12: 12 Web basics every Java web developer must know – Part 2.

Java Developer Interview Q&As

800+ Java Interview Q&As