SHCDAS: Web Browsers, Web Servers, and Application Servers

This blog post is part of the SaaS Headless Content Delivery Architectures Series.

To oversimplify a bit, consider the Internet as only clients that use web browsers to access servers that host websites. Websites consist of HTML pages that contain external content, CSS styles, JavaScript including data in JSON format, images and other media, and other resources. HTML and JavaScript reference additional styles, scripts, media, and services for the client to retrieve from additional HTTPS service endpoints. For example, pages may use JavaScript to send information about the visitor to analytics engines or retrieve additional content from a search or content management system for the browser to render or otherwise use in the page.

Web servers listen for HTTP requests on specific TCP/IP ports and for specific DNS entries and IP addresses. Browsers place requests to web servers using the HTTP (unsecured) and HTTPS (encrypted) Internet protocols. Web servers respond by serving the resource that corresponds to the requested URL, such as the file at the path that corresponds to the URL path under the directory that corresponds to the web server document root of the website that matches the DNS entry in the requested URL. A Content Delivery Network (CDN) may cache the response from the web server to optimize performance for clients that subsequently request the same URL.

Application servers extend web servers by adding logic during to the process of serving HTML and other resources rather than simply serving files from disk. Application servers invoke server-side platform technologies such as ASP.NET, Java, NodeJS, PHP, Ruby, and otherwise to generate output dynamically for each HTTP request.

Each HTTP requests can contain a great deal of information, including:

• Information about the device placing the request, including the operating system, browser capabilities, language preferences, and otherwise.
• Cookies created by websites to store information about or for the visitor.
• The protocol and TCP/IP port number, such as HTTPS and 443.
• The fully-qualified domain, such as subdomain.domain.tld.
• The full-qualified URL path, such as /about.
• Query string parameters, especially for HTTP GET requests.
• An HTML payload, such as a JSON representation of the values in form fields, hidden variables, or elsewhere in the page, especially for HTTP POST requests.
• The URL of the referring page, such as the page that contained the link that the visitor clicked to access the requested URL.

Cookies can identify sessions and visitors, allowing the application to access information about visitors stored in external systems such as tagging and profiling networks.

The technical difference between HTTP GET and HTTP POST requests is generally irrelevant for architectural considerations. Both GET and POST are considered HTTP requests whether encoded using HTTPS or not.

When a client such as web browser requests the URL of a page, the web server typically responds with HTML for the browser to render as a page. That HTML response can contain styles (CSS) and JavaScript, and can reference additional URLs for style, script, media, and other resources for the client to apply or embed while rendering the page. JavaScript running in the page can send information to external services, such as to track and profile visitors, and to retrieve additional resources from external systems, such as to consume services from content management, search, tag management, and other providers that return JSON.