Web Development Basics

Learning Objectives

  • Define web development and distinguish between frontend and backend.
  • Explain the Client-Server architecture and the HTTP request/response cycle.
  • Identify the core frontend technologies (HTML, CSS, JavaScript) and their roles.
  • Understand the Document Object Model (DOM) and how JavaScript interacts with it.
  • Define REST APIs, common HTTP methods (GET, POST, PUT, PATCH, DELETE), and basic status codes.
  • Distinguish sessions/cookies, access tokens/JWTs, OAuth 2.0, and OpenID Connect.
  • Recognize common web security vulnerabilities such as XSS and CSRF.

An introduction to building websites and applications, covering the Client-Server architecture, HTML/CSS/JavaScript, the DOM, REST APIs, and Authentication.

Web Development

Web Development is the process of building, creating, and maintaining websites and web applications that run online within a browser. It is generally divided into two main areas: Frontend (what the user sees and interacts with) and Backend (the server, database, and logic that powers the application behind the scenes).

HTTP

HTTP (Hypertext Transfer Protocol) is the foundation of data communication for the World Wide Web. It functions as a request-response protocol in the client-server computing model.

API

An API (Application Programming Interface) is a set of rules and protocols that allows different software applications to communicate with each other. In web development, APIs usually refer to web services that expose data and functionality over HTTP.

1. The Client-Server Architecture

The web commonly uses a client-server model: a client such as a browser requests a resource or service from a server. The server may run application logic and use a database before returning a response. A server can also delegate work to other services; the drawing below shows a simplified exchange.

  • 1. Name resolution: The browser or operating system uses a DNS resolver to obtain an address for the hostname when needed. DNS resolution and connection setup happen before the HTTP exchange with the selected server.

  • 2. The request: The client sends an HTTP request to the server. HTTPS protects HTTP traffic in transit with TLS; a request commonly carries a method, target, headers, and sometimes a body.

  • 3. The response: The server returns a status code, headers, and usually a representation such as HTML or JSON. Some responses have no body, and one page may require additional requests for stylesheets, scripts, images, or data.

  • 4. The browser: The browser interprets the response according to its media type and updates the page. Client-side code can update parts of a page without a full navigation, when the application is designed to do so.

A simplified browser and server exchange

The DNS lookup may be cached, and real systems can include proxies, content delivery networks, or multiple services. The server-to-data-store exchange is optional. The HTTP response, including its status and headers, travels inside the TLS-protected HTTPS connection and may contain a representation such as HTML or JSON.

The diagram shows a browser resolving a hostname through DNS, sending an HTTPS request to an application server, and receiving an HTTPS response over the TLS-protected connection; server work may include optional data-store access.

2. Frontend Development (The Client Side)

Frontend development focuses on everything the user directly interacts with in their browser. It is built using three core technologies: HTML, CSS, and JavaScript.

2.1 HTML (HyperText Markup Language) HTML provides the Structure or skeleton of the webpage. It uses "tags" to define semantic elements like headings (<h1>), paragraphs (<p>), links (<a>), and images (<img>).

2.2 CSS (Cascading Style Sheets) CSS provides the Styling or visual presentation. It controls layout, colors, typography, spacing, and responsive design (using Media Queries to make the site look good on both small mobile phones and large desktop monitors).

2.3 JavaScript (JS) JavaScript provides the Interactivity and logic. It allows the page to respond to user actions (like clicking a button, validating a form, or fetching new data) dynamically, without needing to reload the entire page from the server.

DOM (Document Object Model)

The DOM is an application programming interface for web documents. It represents the page so that programs can change the document structure, style, and content. The DOM represents the document as nodes and objects (a tree structure).

DOM Manipulation Example

While parsing HTML, a browser constructs a document tree. JavaScript can select a node and update it—for example, document.querySelector("#status").textContent = "Saved" changes that element's text. A script can also change styles or attributes, subject to browser APIs and application logic.

HTML parsing creates a DOM that JavaScript can update

The DOM is a programmable node representation of the document. The example changes the paragraph's text node; it does not rewrite the original HTML source file.

The figure maps a short HTML fragment to a document tree, then shows a JavaScript textContent assignment changing the paragraph node from Ready to Saved.

Use the tabs to inspect example HTML, CSS, and JavaScript. Toggle CSS styling and JavaScript behavior in the preview; the HTML structure remains present throughout.

Web Layers

<!-- Structure -->
<div class="card">
<h2>Welcome</h2>
<button id="btn">Click Me</button>
<p>Clicks: <span id="count">0</span></p>
</div>
localhost:3000

Welcome

Clicks: 0

3. Backend Development (The Server Side)

Backend development involves the server hardware, the database, and the application logic that powers the website behind the scenes, ensuring data is processed securely and efficiently.

  • Server Environment / Framework: Software running on the server that listens for incoming HTTP requests and routes them to the correct logic. Examples include Node.js (Express), Python (Django/Flask), Java (Spring Boot), PHP (Laravel), or Ruby on Rails.

  • Database: Systems used to permanently store application state, user accounts, products, posts, etc. Can be Relational (PostgreSQL, MySQL) or Non-Relational (MongoDB).

  • Application Logic (Business Rules): The custom code that acts as the bridge between the database and the frontend, processing calculations, verifying passwords, and enforcing security checks before sending data back.

3.1 REST APIs (Representational State Transfer)

A REST API is an interface designed around the constraints of Representational State Transfer. Web APIs often use HTTP methods to act on resources, but method names alone do not make an API RESTful. JSON is common for API representations; HTTP also carries other media types.

Common HTTP methods and properties:

  • GET: Retrieve a representation. It is defined as safe: the client does not request a state change, though incidental effects such as logging can occur.
  • POST: Submit a representation for processing; the target resource defines the processing, which may create a resource or trigger another action.
  • PUT: Create or replace the state of the target resource with the supplied representation. Repeating the same request has the same intended effect.
  • PATCH: Apply partial modifications to a resource. Whether repeating a PATCH has the same intended effect depends on the patch operation.
  • DELETE: Remove the association between the target resource and its current functionality. It is defined as idempotent, even when repeated responses differ.
HTTP methods describe intended request effects

Safe means the client does not request a state change; idempotent means repeated identical requests have the same intended effect as one request. PATCH idempotence depends on the patch document, and an API's resource semantics still matter.

Five method cards summarize GET, POST, PUT, PATCH, and DELETE, including their common purpose and whether the method is defined as safe or idempotent.

3.2 HTTP Status Codes

An HTTP response includes a status code that indicates how the server handled the request. The first digit groups codes into broad classes; a specific code and its method context provide the more precise meaning.

  • 1xx (Informational): The request was received and processing continues.
  • 2xx (Successful): The request was successfully received, understood, and accepted. 202 Accepted means processing was accepted but may not be complete; 201 Created indicates a resource was created.
  • 3xx (Redirection): The user agent needs to take further action, often by following a redirect.
  • 4xx (Client error): The server considers the request to have an error, such as invalid input or missing authentication. 401 indicates authentication is required or invalid; 403 means the server understood the request but refuses it.
  • 5xx (Server error): The server failed to fulfill an apparently valid request.
HTTP status code classes and common distinctions

Status classes summarize response meaning. Read the specific status code and the request method's semantics; a 2xx response does not always mean background work has finished.

Five stacked bands explain the 1xx through 5xx response classes, with examples highlighting that 202 is accepted but not necessarily complete and that 401 and 403 have different meanings.

4. Authentication and Security Basics

Web applications must securely verify who a user is (Authentication) and what specific actions they are allowed to perform (Authorization).

Authentication Mechanisms:

  • Cookie-carried session identifier: After authentication, a server can create a session and send a cookie containing an opaque session identifier. The browser stores and sends applicable cookies automatically under cookie rules; the server or session service looks up the session. Session state need not be kept in one server's memory.

  • Bearer access token: A client commonly sends an access token in an Authorization: Bearer … header. Whoever possesses a bearer token can use it, so it must be protected. A JSON Web Token (JWT) is one possible token format: it can be integrity-protected or encrypted, while some access tokens are opaque. Using tokens does not by itself require a stateless server design.

  • OAuth 2.0 and OpenID Connect: OAuth 2.0 is an authorization framework for delegated access. OpenID Connect adds an identity layer used for authentication. In a standard authorization-code flow, the application receives authorization results without collecting the user's identity provider password.

Cookie sessions and bearer tokens cross different trust boundaries

These are common patterns, not mutually exclusive architectures. A token may be opaque or a JWT, and a JWT may be signed or encrypted. Authentication identifies a principal; a separate authorization decision determines what that principal may do.

Two stacked panels compare a browser sending an applicable session cookie that references server-managed state with a client presenting a bearer access token for server validation.

Common Web Vulnerabilities

Cross-site scripting (XSS) occurs when untrusted data is handled so that it executes as script in a user's browser. Prevention depends on context-aware output encoding and safe APIs; if an application intentionally accepts HTML, it also needs a suitable sanitizer. Cross-site request forgery (CSRF) tricks a user's browser into sending an unwanted authenticated request to a site. Defenses depend on the application and can include anti-CSRF tokens, origin checks, and appropriately configured SameSite cookies.

Key Takeaways
  • In a common web exchange, a client sends an HTTP request and a server returns a status, headers, and possibly a representation; HTTPS adds TLS protection in transit.
  • HTML defines document structure, CSS presentation rules, and JavaScript behavior; the DOM exposes a programmable representation of the document.
  • HTTP method semantics include safety and idempotence, while response status codes summarize how a request was handled.
  • JSON is a common API representation, but HTTP supports other media types.
  • Authentication establishes identity, and authorization decides whether that identity may perform an action.
  • Cookies can carry session identifiers; bearer access tokens are commonly sent in an Authorization header, and JWT is one token format.
  • Context-aware output handling helps prevent XSS, while CSRF defenses protect authenticated requests from unwanted cross-site initiation.

References