Web Basics

What do you understand by client side and server side templating?

The modern rich single page web applications built today harness the power of dynamically typed and interpreted languages like JavaScript for faster prototyping and increased developer productivity and statically typed Java based frameworks for maintainability, robustness, easier refactoring, and scalability. The modern browsers using faster JavaScript engines and efficient minification of JavaScript files have made client side templating a reality.

• The server side templates are such as JSPs, Facelets for JSF, Apache Velocity, tiles, Sitemesh, etc.
• The client side templating libraries based on JavaScript include AngularJs, Backbone, ember, etc

Server side view technologies

In server-side view technology the most of the page rendering happens on the server side. The server side view technologies are JSPs, Thymeleaf, Facelets for JSF, Apache velocity, Sitemesh, etc.

Generates the HTML on the server, returns the generated HTML code to the browser. So these technologies are page centric as the browser will be requesting for different pages.

Client side view technologies

In client-side view technology the most of the page rendering happens on the client side. The client side templating libraries based on JavaScript based frameworks like AngularJs, ReactJs, Backbone, Ember, etc

The client side view technologies are based on a rich single page application (SPA) where the page rendering happens on the browser (i.e. client side). Client side will be making RESTful web service calls via ajax requests to the back end server. On the server-side RESTful web services implemented with say Spring-MVC will be processing the ajax request and responding with JSON data to the browser, and the client side technology will be rendering or refreshing portions of a rich page.

JavaScript templating is a technique to render templates on client-side (i.e. within the browser) with JavaScript using a JSON data retrieved via RESTful web service calls. The template is basically HTML markup, sprayed with tags and variables that will insert values from the JSON data or execute a programming logic.

Which view technology would you use?

If you want a rich web application with lots of user interaction and page state changes, then client side technology like AngularJs might be the way to go.

If you want page with simple and finite number of interactions then server side technology like JSP or Thymeleaf might be the way to go.

What are the pros & cons of both server & client side technologies?

Server Side Templating

Pros:

• More search engine friendly.
• Entire response message can be cached.
• Can work without JavaScript

Cons:

• 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

Pros:

• 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, J2EE, Ruby, etc

Cons:

• Less search engine friendly
• Older browsers may not work properly
• Cross browser compatibility testing is required

How will you go about building client side view technology with server side micro-services for data in Java?

Spring boot for micro-services and AngularJs as the client side templating.

Also look at JHipster https://jhipster.github.io/ for Spring Boot + AngularJs Web applications and Spring .

HTTP basics

 

What happens when you open up a browser and type a URL to request a Web page or RESTful web service?

HTTP is a stateless protocol on top of TCP (Transmission Control Protocol).

1) When the IP address is obtained, the browser will attempt to open a TCP connection to the web server, usually on port 80.

2) Once the TCP connection is made, the browser will issue an HTTP request to the server using the connection.

3) The HTTP request comprises a header section, and possibly a body section, which is where POST data go, and in GET request the parameters are passed in the URI.

4) Once the request is sent, the browser will wait for the response.

5) When the web server has assembled the response, it is sent back to the browser for rendering. The HTTP response consists of a header section and a body. The header section tells the browser how to treat the body content and the browser renders the content for viewing. Each HTTP response includes a status code, which indicates the status of
the request.

6) “headers” are sent before the actual page content. These headers are invisible, but can be viewed via development tools like Firefox plugins and in Chrome with “Developer tools”. The browser uses the Content-Type header to determine the type of data sent like text, xml, json, etc. This is also known as the MIME type of the particular Web resource.

7) The common response status codes include, 200 OK, 404 NOT FOUND, 500 Internal Error, etc.

8) Most HTTP responses will also contain references to other objects within the body that will cause the browser to automatically request these objects as well. Web pages
often contain more than 50+ other object references like style sheets (i.e. CSS), images, JavaScript files, etc to complete the page. Your browser will create additional TCP connections for these referenced references. For example, 2 to 3 connections per host.

The basic request is comprised of

1) a method –> GET, POST, PUT, DELETE, HEAD, and OPTIONS
2) the URI (Uniform Resource Indicator) –> a RESTful API ends up being simply a collection of URIs. To read a customer with Customer ID# 725, http://www.myhost.com/customers/725
3) HTTP version desired –> 1.0 or 1.1

What are HTTP headers? Why do you need them?

HTTP headers carry information about behavior between the browser and the web server. The headers are sent by the web server to tell the browser how to treat the content. For example, the “Content-Type” header tells what type of data to expect XML, JSON, HTML, etc.

The “Content-Disposition” header tells browser to display the content on the browser (i.e. inline) or as a download (i.e. attachment) to be saved on to the file system with a popup window. ****

“Connection: Keep-Alive” header will reuse TCP connections for subsequent requests and will save on the latency incurred especially in applications that utilize Web 2.0 technology such as AJAX (Asynchronous JavaScript and XML) to perform real-time updates of content as it reduces the overhead associated with opening and closing TCP connections.

Cookies are sent by the web server to the browser as an HTTP header and used to store all sorts of information about a user’s interaction with the site. A cookie is a small plain text file without any executable code that is stored by a browser on the user’s machine. A web server specifies a cookie to be stored by sending an HTTP header called Set-Cookie.

 HTTP/1.0 200 OK
Content-type: text/html
Set-Cookie: name=value
Set-Cookie: name2=value2; Expires=Wed, 09 Jun 2021 10:18:14 GMT

When a cookie is present, and the optional rules allow, the cookie value is sent to the server with each subsequent request. The cookie value is stored in an HTTP header called Cookie.

What is an HTTP-Only cookie?

The idea behind HTTP-only cookies is to instruct a browser that a cookie should never be accessible via JavaScript through the document.cookie property. This feature was designed as a security measure to help prevent cross-site scripting (XSS) attacks perpetrated by stealing cookies via JavaScript.

How will you go about debugging the data sent from the server on the client-side like header info, cookies, resources sent, debugging CSS, JavaScript, etc?

With the help of browser debug tools like Fire fox plugins like FireBug, Live HTTP Headers, Modify Headers or in Chrome More Tools –> Developer Tools from the main.
menu.

HTTP is a stateless protocol, so how do you maintain state? How do you store user data between requests?

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.
session.invalidate();

Session tracking uses cookies by default. What would you do if the cookies are turned off?

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.

http://localhost:8080/myWebCtxt/purchase.do;jsessionid=4FB61319542B5D310B243E4BDD6DC64B

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

• response.encodeURL(givenURL) to associate a session ID with a given URL and
• if you are using redirection then response.encodeRedirectURL(givenURL).

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.

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.

Http://MyServer:8080/MyServlet?Firstname=Peter&Lastname=Smith

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.

Are states bad? if yes, why?

State isn’t bad, it’s a necessity. But favor stateless architecture for the number of reasons described below.

— The single page rich web pages 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.

What is the structure of an HTTP request and response?

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.

What is your understanding of HTTP URLs, HTTP Verbs, and HTTP status codes?
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. he most common code is 200 OK, which tells the client that the request was successfully processed.

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

Forward

— 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).

Redirect

— 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.

Post-back

— 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 the user the 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.

What is exactly is an Ajax request?

Ajax is browser 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.

Can Ajax makes cross domain requests?

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.

JSONP Example

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.

 

How do you optimize a website’s assets?

CDN (Content Delivery Network) Hosting, re-organizing and refining code, minimizing round trips to/from the server, optimized caching, reducing the payload sizes and compressing payloads (e.g. JavaScript minification, combining files), add an Expires or a Cache-Control HTTP headers to cache web resources like scripts, CSS, images, etc, and moving CSS load in the head section and scripts at the bottom to load faster, etc.

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.

— Clearly separate styles via CSS and JavaScript via script files from the actual HTML content via proper includes.

— 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 compatibility 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.

What is a DOM, and how do you manipulate a DOM?

The DOM (Document Object Model) is a programming API for documents. It defines the logical structure of documents and the way a document is accessed and manipulated. You can think of HTML elements as objects is DOM. It has properties, methods, and events. HTML DOM is a standard for how to get, change, add, or delete HTML elements. For example, manipulate the DOM via JavaScript or selecting the elements via jQuery selectors. Google chrome browser’s “developer Tools” or Fire fox’s “Firebug” plugin can be used to view the DOM elements and perform client side debugging