DI-322 Web Technologies Lecture 16: Integrating and defending a web application
DI-322 Web Technologies
0% Completed

Lecture 16: Integrating and defending a web application

Outcomes and readiness

You can connect browser, HTTP, servlet, service, repository, and database layers; justify design trade-offs; and verify one vertical feature across success and failure. Readiness: bring your artifacts from Labs 04, 08, 13, 14, and 15.

Capstone problem

Build a small Course Planner: list courses, view one course, create a draft course, and search by code/title. This is an instructional application, not a production university system. It must not contain real student data.

flowchart TB
  UI[Semantic HTML + responsive CSS] --> JS[Optional JavaScript enhancement]
  JS --> HTTP[HTTP contract]
  HTTP --> CTL[Servlet controller]
  CTL --> APP[Application service]
  APP --> REP[JDBC repository]
  REP --> DB[(Course database)]
  APP --> CTL
  CTL --> HTTP

Vertical slice walkthrough

For POST /courses: accessible form -> client feedback -> server content-type/size/input validation -> authorization assumption -> application use case -> transaction -> prepared insert -> duplicate detection -> 201 Location or mapped error -> UI success/error state -> sanitized log. Every arrow has a contract and a failure mode.

Faded design task

Where should “course code must be unique” live? Hint 1: browser check can race. Hint 2: invariant must hold under concurrent requests. Solution: enforce with a database unique constraint, interpret the conflict in repository/service, and return a safe conflict response; client-side availability feedback is optional assistance.

Quality and security checklist

  • Semantic, keyboard-usable UI at 320px; no page-wide overflow.
  • Server validation and contextual output encoding.
  • Parameterized SQL, explicit transactions, no credentials in source.
  • Request-local state; thread-safe shared dependencies.
  • Correct statuses/content types/cache rules; no sensitive caching.
  • English/Urdu explanatory UI where implemented, same IDs and grading.
  • Tests for normal, boundary, malformed, unauthorized, not-found, duplicate, database-failure, and concurrent cases.

Common mistakes

  • A working happy path is not complete verification.
  • Hiding a button is not authorization.
  • Framework-generated code still needs understood contracts and tests.

Practical – DI322-LAB16

Implement one complete vertical slice and demonstrate: browser interaction, raw request/response, controller, service, repository, database change, and reload. Then inject three failures. If the environment cannot run the stack, produce a compilable/reviewable project and mark each unexecuted check; do not claim a live app.

Independent check – DI322-A16-Q1

Given a bug where two users create the same code, name one insufficient fix and the durable control. Answer: disabling the button/client check is insufficient; a database uniqueness constraint plus conflict handling is durable.

Homework/project – DI322-A16-H1

Complete the Course Planner and a five-minute defense. Full specification and 100-mark rubric are in ../projects/integrated-project.md. Submit architecture, contracts, source, schema, test evidence, security review, and known limitations.

Revision

Explain the system from the user’s action to stored data and back. At every boundary ask: what enters, who trusts it, what can fail, and how is that failure represented?

PreviousNext