Server-Side Web Programming

🎯Learning Objectives

• The last lessons handled browser events, API responses and local preferences.
• This lesson follows the other end of the request: the application that decides what response to return.
• You will separate a browser interface from server-owned data, trace a handler pipeline and explain why a client-side check cannot protect a backend.

• Our example is a small workshop service.
• Guests can read the catalog, recognized users can create bookings, and an administrator can inspect an aggregate report.
• The interactive lab simulates this pipeline locally so you can inspect every decision without needing a backend account.

🖥️Where Does the Code Execute?

• Browser code controls the interface in the learner’s device.
• Server-side code executes in a backend environment and produces responses to requests.
• Both can use JavaScript, but they have different capabilities, inputs and trust boundaries.
• A filename ending in .js does not tell you where that code executes.

• A server can work with private configuration and shared records that are not shipped to every browser.
• Browser scripts can read and change their own interface, and users can inspect or modify what that browser sends.
• Sending a secret inside frontend JavaScript does not make it private.

• For the workshop example, the browser displays available places and collects a requested quantity.
• The backend must decide the current capacity and whether to create a booking.
• A learner cannot authorize a reservation by changing a displayed counter or sending an admin field.

• The lab intentionally puts both sides into one page for teaching.
• That makes its “server” inspectable and editable too.
• It demonstrates the order of checks; it cannot provide the protection of a separately deployed backend.

Static Resources and Dynamic Responses

• A static resource can be returned from a stored file, such as a course HTML page, image or stylesheet.
• A dynamic response is computed from request information and application state.
• A workshop catalog may be generated from current records even when its visual layout stays the same.

• A dynamic application still serves static assets.
• Its HTML may reference ordinary CSS and JavaScript files.
• A static frontend can also call a separate dynamic API; server rendering is not required for every feature.

• Consider two learners requesting their bookings.
• The route can be identical, but the recognized identity determines which records are returned.
• The response must be based on the correct user’s records rather than a browser-supplied user ID treated as authority.

• “Dynamic” describes how a response is produced, not whether the page has animations.
• A frontend animation can run entirely in the browser, while a visually plain page can be generated dynamically.

📨Read the Request: Method, Path, Headers and Body

• A request describes an operation.
• Its method conveys intended semantics, the path selects the target, headers carry metadata and the body can contain submitted data.
• Query parameters belong to the URL and need their own parsing and validation.

• Our lab’s POST /bookings request uses a JSON body with exactly workshopId and seats.
• Content-Type identifies the supplied representation.
• An Authorization header carries a visibly fake fixture token so the local simulator can look up a predefined identity.

• The preview shows what the simulator receives.
• GET handlers ignore the body controls; POST /bookings parses the body only after route, method and identity checks.
• This deliberate order is part of the exercise’s contract, not a requirement that all real frameworks have an identical middleware order.

POST /bookings HTTP/1.1
Content-Type: application/json
Authorization: Bearer fixture-learner

{"workshopId":"html","seats":1}

• This is an illustrative request, not a live endpoint or usable credential.
• A real client and backend must agree on their contract, transport and authentication mechanism.
• Do not paste real tokens into the teaching lab.

🧭Routing — Match the Target Before the Handler

• A router maps a method and path to a handler.
• Known paths may permit different methods.
• In our simulation, GET /workshops reads the catalog; GET /bookings reads the current identity’s bookings; POST /bookings attempts a new booking.

• An unknown path returns 404.
• A known path with an unsupported method returns 405 and an Allow header listing the methods this simulation supports.
• DELETE /workshops is therefore different from GET /missing.

• Do not treat a path as a filename or execute arbitrary code based on it.
• A framework normally offers explicit route declarations and parameter parsing.
• The simulator uses a fixed route map so you can see the decision without learning one framework’s syntax.

• The toy router models only the listed methods.
• It does not implement a full web server’s handling of HEAD, OPTIONS, query strings, trailing slashes or URL decoding.
• A production router needs those decisions to be tested against its documented behavior.

🛠️Methods Describe the Intended Operation

• GET is intended for reading a representation without requesting a state change.
• A request can still produce logs or other incidental effects, but a GET route should not book places merely because a learner follows its link.

• POST asks a target to process supplied data according to its contract.
• In the lab, an accepted POST creates a booking.
• Repeating the same request creates another booking if capacity permits; this exercise does not implement deduplication or an idempotency key.

• Do not assume that POST encrypts its body.
• HTTPS protects transport, while server validation and authorization decide what the operation may do.
• Keeping a value out of a query string does not make it trustworthy.

// Contract examples — not live calls from this page:
// GET /workshops       -> read current catalog
// GET /bookings        -> read this identity's bookings
// POST /bookings       -> attempt to create a booking
// DELETE /workshops    -> unsupported here: 405

• For a real create operation, decide what retries mean.
• Network failure can leave a client uncertain whether a write completed.
• A server-side idempotency strategy can make intended retries safe; merely disabling a browser button is insufficient.

✅Parse Input, Then Validate Its Meaning

• A JSON parser checks text syntax and produces a value.
• It does not prove that the value contains the right fields or types.
• A valid JSON string, array or null is unacceptable for our booking object.

• The exact lab contract is {workshopId, seats}.
• WorkshopId must be html, css or javascript.
• Seats must be a numeric integer from 1 to 3.
• Extra fields, including a client-supplied role or userId, are rejected.
• The accepted booking owner is derived from the recognized identity.

• The body must be JSON and at most 2048 characters for this local exercise.
• In a deployed service, request-byte limits should also be enforced before an unbounded body is read or parsed.
• Browser maxlength and HTML validation improve feedback but can be bypassed.

const parsed = JSON.parse(rawBody);
// Check exact shape, allowed workshopId and integer seats.
const accepted = validateBooking(parsed);
// A loaded "1" string is not the required numeric 1.

• Our API chooses 400 for malformed JSON or invalid fields and 415 for an unsupported media type.
• Other APIs may use a different documented validation status.
• The important behavior is a clear rejection before changing records.

🔄A Handler Pipeline with Clear Boundaries

• A handler often follows several stages: route selection, identity checks, parsing, validation, business rules, a data operation and response construction.
• Keeping these stages clear makes failures easier to explain and test.

• The simulator first checks route and method.
• Protected routes then identify the caller.
• An admin-only handler checks its role.
• The booking handler checks media type, parses bounded text, validates the data, checks remaining places and finally commits one change.

• An early rejection ends the pipeline.
• A request with an invalid identity never reaches the booking mutation.
• The trace records which stage accepted or rejected the request, and the response explains the outcome without showing internal stack traces.

• Real frameworks may place some checks in middleware shared by many handlers.
• Shared middleware reduces repetition, but you still need to know what data it validates and what trusted identity it supplies to a route.

📤HTML Templates and JSON APIs

• A backend can render an HTML document using a template and records, or return JSON for a browser script to render.
• These are two representation choices.
• The same application may use both for different routes.

• Templates separate a layout from values inserted into it.
• Use the template engine’s appropriate escaping behavior and avoid treating untrusted input as trusted markup.
• For a JSON API, validate the output contract and render values as text where HTML is not intended.

• The lab returns JSON-shaped response objects.
• Its response panel is not an HTTP connection; it displays status, headers and body so you can inspect the contract.
• All displayed values use textContent.

// JSON response concept:
{
  "id": "booking-1",
  "workshopId": "html",
  "seats": 1
}
// A template could instead place these values into an HTML page.

• A successful status and correct Content-Type should match the returned representation.
• Do not make a client guess whether a body is a JSON result or an HTML error page.
• The API loader in Level 18 already demonstrated why status checking and body parsing are separate stages.

🗃️Shared Data and Business Rules

• A real workshop service needs shared, durable records.
• Two learners should not each receive a separate unlimited supply of places merely because they opened different browser tabs.
• A database or other server-owned store can provide the shared state.

• Input validity and business validity differ.
• The number 2 can be a valid requested quantity, but a workshop with only one remaining place cannot accept it.
• Our lab returns 409 for that conflict and leaves its records unchanged.

• The simulation begins with HTML: 3 places, CSS: 2 and JavaScript: 0.
• A successful booking decreases the selected remaining count and adds a booking.
• It is a synchronous memory exercise, so it does not demonstrate database durability or concurrent transactions.

// Illustrative SQL shape; bind parameters through the driver.
UPDATE workshops
SET remaining = remaining - :seats
WHERE id = :id AND remaining >= :seats;
// Check affected rows and insert the booking in one transaction.

• The statement is a design illustration, not a complete database program.
• In a real implementation, the capacity update and booking insert must succeed or roll back together, with an appropriate concurrency strategy.
• A browser counter and a separate check-then-write are not enough.

🪪Sessions Connect Requests to an Identity

• HTTP requests do not themselves carry an application’s remembered user object.
• An application may use an identifier to look up server-owned session state.
• That state can include a user ID, expiry and relevant authentication context.

• A common browser flow uses a session cookie managed by the server.
• Other applications use explicitly supplied authorization tokens.
• These mechanisms have different security and lifecycle requirements.
• Session storage in the browser is not the server session and cannot establish an authenticated identity by itself.

• Our lab uses public fake Bearer fixture tokens to select guest, learner, administrator or expired identity behavior.
• A predefined lookup supplies the mock user and role.
• There is no login, password, real cookie, secret credential or verified account in this page.

• In a real service, identifiers must be created and protected appropriately, and sessions must expire or be invalidated when required.
• Do not copy the lab’s fixed strings into a production authentication system.

🔐Authentication and Authorization Answer Different Questions

• Authentication establishes who the caller is under the application’s rules.
• Authorization checks whether that caller may perform the requested operation on the target resource.
• A recognized learner is still not an administrator.

• The simulator returns 401 with a Bearer challenge when a protected route lacks a recognized fixture.
• It returns 403 when the learner requests /admin/report.
• Public /workshops does not require an identity.

• For GET /bookings, the response is filtered by the user ID obtained from the lookup.
• A request body cannot nominate a different owner.
• For POST, the record’s owner is assigned by the handler.
• This avoids making ownership depend on a client-editable field.

• Authorization belongs on the server at every protected operation.
• Hiding an admin button or disabling a control only changes the interface; it does not prevent a user from sending the request another way.

⚠️Status Codes and Useful Failure Responses

• A status should describe the outcome, while the body gives enough information for the caller to respond.
• The simulator uses 200 for accepted reads and 201 for a newly created booking.
• A success message appears only after its mock commit.

• Failure responses are deliberate: 400 invalid body, 401 unrecognized identity, 403 insufficient role, 404 unknown path, 405 unsupported method, 409 capacity conflict, 415 wrong media type and 500 the injected failure before commit.
• A failed request does not create a booking.

• The server-failure switch affects only an otherwise acceptable POST booking and triggers before mutation.
• Invalid requests still fail at their earlier checks.
• This ordering helps learners separate a validation error from a backend operation failure.

• A real server can log diagnostic details privately while returning a stable public error.
• Avoid leaking credentials, database statements or stack traces in responses.
• The trace in this teaching page is intentionally a visible explanation, not production logging.

🛡️Security Is More Than Input Validation

• Validate inputs on the backend, but also use defenses appropriate to where the data goes.
• Parameterized database queries keep values separate from query code.
• Output escaping or encoding depends on the destination context.
• Authorization checks keep records limited to permitted callers.

• Cookie-authenticated state-changing requests need a deliberate cross-site request forgery strategy, such as the framework’s validated CSRF protection.
• SameSite cookie policy can contribute, but choosing POST alone is not a complete defense.
• The fixture lab does not model cross-site requests or implement production CSRF protection.

• Keep secrets in backend configuration rather than public assets.
• Use HTTPS, resource limits, dependency maintenance and appropriate logging.
• Each protects a different part of the application; none turns a client-controlled role field into authority.

// Unsafe design idea:
// authorize(request.body.role === "admin");
// Better boundary:
// recognized = verifyCredential(request);
// requirePermission(recognized, "view-report");

• The commented names above describe responsibilities, not a ready-made security library.
• Use a framework’s documented facilities and test the entire application flow.
• The next language lessons can implement these concepts within their own runtime.

🧩Runtime, Configuration and Deployment

• A backend needs an environment that can execute its language and accept requests.
• Uploading PHP or Python source beside static frontend files does not make a static file host execute it.
• The hosting setup must provide the matching runtime or a separately deployed service.

• Configuration commonly includes service URLs, database access and secrets.
• Distinguish public settings needed by the browser from private values used only by the backend.
• A frontend repository should not become a delivery mechanism for database credentials.

• Keep browser and backend changes connected through a documented API contract.
• A health response can confirm that a service answers a basic check, but it does not prove that booking validation, authentication or a database write works.
• Test those flows separately.

• This lesson ships only frontend teaching files.
• It neither deploys an API nor adds a database.
• The local lab is useful preparation, and its request paths remain hypothetical until a real backend implements them.

🧭Connect the Browser to a Tested Backend

• Start with one complete flow rather than many unexplained endpoints.
• Define a catalog read and a booking create contract.
• Implement the server checks and data operation, then connect the browser with clear loading, success and failure states.

• The browser should inspect status, parse the expected representation and validate what it displays.
• The backend should validate and authorize independently, even if the browser already rejects bad inputs.
• These complementary checks serve different responsibilities.

• Test missing identity, a wrong role, malformed data, insufficient capacity and a failed write.
• For a durable system, also test retries and concurrent requests.
• A successful local simulation does not establish that a deployed runtime or database behaves correctly.

• The visualizer below follows an accepted booking.
• The interactive lab lets you interrupt the flow at different stages and inspect the unchanged or updated mock state.
• Next, PHP Fundamentals will introduce a concrete server language while preserving these boundaries.

🧪Premium Interactive — Workshop Backend Simulator

• This is a local simulation, not a deployed API, login or real booking service.
• It sends no network requests and creates no cookies.
• All fixture identities and mock records are public teaching data in this page.
• Refresh or Reset simulator restores the starting state.

• Choose a method, path and fake identity fixture.
• GET /workshops is public.
• Protected reads require a recognized identity; /admin/report requires the admin fixture.
• POST /bookings accepts exactly workshopId and numeric seats from 1 to 3.
• It assigns ownership from the fixture lookup, not the body.

• Start with HTML: 3 places, CSS: 2 and JavaScript: 0.
• Successful bookings consume places; repeated accepted POSTs create additional bookings.
• The injected failure affects only an otherwise valid POST before commit.
• Inspect the request, staged trace, response and mock state after every action.

No request yet.

No trace yet.

No response yet.

Starting places: HTML 3, CSS 2, JavaScript 0. No bookings.

🛠️Debugging — Find the First Failed Check

• If a guest POST returns 401 instead of 400 for bad JSON, inspect the trace: this handler checks identity before parsing.
• If a learner cannot open the report, signing in as that learner again does not supply the administrator permission.

• If a valid request receives 409, read the current mock remaining count.
• Repeated successful POSTs have already consumed places.
• Reset restores the fixtures, but it also deliberately clears all bookings in this simulation.

• If a failed request changes mock state, compare the mutation boundary with the rejected stage.
• A production database requires its own rollback and concurrency tests; the synchronous simulator does not establish those properties.

💬Interview Questions — Flip to Explain

❓MCQ Practice — Trace the Backend Decision

💻Extra Practice — Predict and Verify the Response

📌Quick Revision

📖Glossary — Flip to Learn

🏆Final Challenge — Specify a Real Booking Service

• Write a contract for catalog reads, protected booking creation, own-booking reads and an administrator report.
• Specify methods, fields, body limits, identity requirements, permission checks and deliberate status codes.
• Separate browser feedback from backend enforcement.

• Trace each lab scenario and state which check fails first.
• Keep malformed input, denied requests, capacity conflicts and a failed commit from changing records.
• Explain why ownership comes from trusted identity and why a repeated POST may need an idempotency design.

• For a deployed implementation, select a runtime, protected configuration and shared data store.
• Use a suitable transaction for capacity and booking records, then test concurrent requests, retry behavior, sessions and real HTTP responses.
• Do not claim those guarantees from the browser simulation alone.

• Success criterion: describe a complete request-to-response flow with clear boundaries and honest outcomes.
• Level 21 introduces PHP Fundamentals as a concrete server language.