Draft Table of Contents for TAG work on Web Architecture for Web Applications
- Revised 2009-09-21
- Version of 2009-06-25
I have included all the relevant topics I could think of, expecting
that we will strike or stub out all the ones on which we have nothing
in particular to say. -Jonathan
Network effects, overall user experience (not just at
your site), robustness,
enabling automation. You should read this document
if and only if you care about these objectives.
Web of documents to web of services to web of
applications; ever larger user community; access to web
from all sorts of devices (phones being notable for
penetration and ubiquity).
- What is a web application?
It's a matter of degree, yes? Has to
do with the volume, richness,
durability, and server/client distribution of state.
- Use cases:
Involving both end users (browsers-mediated, e.g. mobile) and
automated agents (behind the scenes and/or "scripted" use of
- Application state
- What is state?
Client and server (or sets of peers) form a
system, and it is the system that has state.
- Where is the state?
On a display, in URIs (cf. Raman's
note), in the browser history,
in the DOM (e.g. hidden form inputs), cookies, server-side, in and
out of memory.
"Stateless" means the state is on the client.
Bookmarks, cookies, databases (both client and server side)
What should be done to make an application friendly to
automation (automated agents)?
- State transitions
- Expressing desired transitions:
Declarative vs. procedural. API good practices.
- Transmitting transition requests:
XMPP/Comet/HTML Web Sockets.
Potential user confusions: What state is the system in?
- Using HTTP:
When to use HTTP vs. some other mechanism. The usual advice
around GET and POST.
- Designating and accessing state and other resources
- Identifying states:
Cookies, URIs, etc. To designate or not to
designate. A designated states might be dead.
Gaining access to state. Server
authentication and phishing. Client authentication. Session
Controlling ability of
isolated components to interact. Sandboxing.
- Multiple principals:
Some systems involve more than two principals ("mashups").
Delegation = agent A asks agent B to interact with agent C on
its behalf. Access control (both server and client side).
Confused deputy risks.
- Identification and authorization.
How are they related?
authority vs. designated authority. Credentials and keys.
APIs and authority.
- API access to personal data and other sensitive resources.
When does a resource need to be
protected. Examples: phone SMS, /dev/* .
- Privacy. Policy (intent) vs. implementation (by
either human organization - companies doing the right thing -
or technique - software that helps prevent things from going
- Constructing and deploying applications
- Names as parameters.
Names in programs/scripts (variables, strings) and names on
the web (URIs). Risks resulting from quotation errors.
- Modules and dependencies.
Designating and authenticating sources.
Of related or interdependent resources. Widgets.
- Resource management:
Installation, offline storage (client-side databases?)