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:
HttpSession session = request.getSession(true); //returns a current session or a new session
//To put/get a value in/from the session
Name name = new Name(“Peter”);
session.setAttribute(“Firstname”, name); //session.putValue(…) is deprecated as of 2.2
session.getAttribute(“Firstname”);//get a value. session.getValue(…) is deprecated
//If a session is no longer required e.g. user has logged out, etc then it can be invalidated.
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.
<input name="”Firstname”" type="”hidden”" value="”Peter”">
<input name="”Lastname”" type="”hidden”" value="”Smith”">
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.
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).
— 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?
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.
Q7. What do you understand by client side and server side templating?
The server side templates are such as JSPs, Facelets for JSF, Apache Velocity, tiles, Sitemesh, etc.
Server side templating and data composition
Generates the markup on the server. For example, returns generated HTML code.
Client side templating and data composition
Generates the markup on the client. More suited for applications that load more data from different back end service providers via AJAX. The services could return data in JSON or XML format and then add the HTML snippets for the new data via the client side templates.
Q8. What are the pros and cons of server side versus client side templating?
Server Side Templating
– More search engine friendly.
– Entire response message can be cached.
– Harder to mix and match different server side technologies. For example, retrieve data from both Java and Ruby based services
– Harder to send content for multiple devices. E.g. browser, mobile devices, etc.
Client Side Templating
– Faster development and prototyping
– Serves JSON data to multiple devices.
– The responses are smaller as JSON data is less verbose.
– Templates and JSON data can be cached.
– Can work with multiple server side technologies like .Net, JEE, Ruby, etc
– Less search engine friendly
– Older browsers may not work properly
– Cross browser compatibility testing is required
Q9. Can AJAX make cross domain requests?
A9. Cross domain requests are in general prohibited by the browser. A cross domain request means, if you have a GUI application (i.e. a war) and a separate RESTful service application as a separate application running on two different domains (i.e different host-name:port no). To overcome this, you have 2 choices JSONP or CORS (Cross Origin Resource Sharing). The CORS is more industrial strength.
If you have a GUI application (i.e. a war) and a separate RESTful service application as a separate application running on two different domains, the you need JSONP for your AJAX to make cross domain calls. In this demo, I will be building a single war and deploy it to two different domains. For example, local and dev. The initial “sum” page will be loaded from the “local” domain, and once you click on the “add” button, the AJAX call will be made to the “dev” domain to get the calculated sum via the RESTful web service call via jsonp callback.
JSONP has a number of limitations like, it supports only GET requests and not PUT, POST, DELETE, etc and it does not also send headers across. CORS stands for Cross Origin Resource Sharing, which allows you to share GET, POST, PUT, and DELETE requests and CORS is supported by the modern browsers.The CORS make use of 2 requests.
Request 1: “OPTIONS” request as part of the handshake to determine if cross domain is allowed by the server.
Request 2: GET, POST, PUT, or DELETE request that performs the actual operation on the server.
Q10. How do you optimize a website’s assets?
Q11. Can you list some of the web development best practices?
— Favor stateless web tier. Stateless web tier means you don’t store any application data in the web server memory or file system. Keeping your web tier stateless enables you to both provide a better customer experience via better performance and your applications can scale well. If the web tier is stateless and it sits behind a load balancer, you can quickly respond to changes in application traffic by dynamically adding or removing servers. In the cloud environment you only pay for server resources that you consume.
— Use a CDN to cache static file assets and for better performance.
— Favor using proven frameworks like angularjs, emberjs, backbone, etc for client-side MVC framewoks, Struts2, Spring MVC, etc for server side MVC, bootstrap for CSS, jQuery for manipulating the HTML DOM, etc.
— Even though the proven frameworks provide cross browser compatibility out of the box, still perform cross browser compatbility testing.
— Perform security penetration or PEN testing using tools like Skipfish from Google, Firefox plugin “tamperdata”, etc to identify security holes in your web application.
— Favor DIV element with style sheets over HTML table elements for your web page layouts.
Q12. What is a DOM, and how do you manipulate a DOM?