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
- Introduction
- Goals:
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.
- Trends:
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
web resources).
- 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.
- Persistence?
Bookmarks, cookies, databases (both client and server side)
- Automation:
What should be done to make an application friendly to
automation (automated agents)?
- State transitions
- Expressing desired transitions:
Representation.
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.
- Authentication:
Gaining access to state. Server
authentication and phishing. Client authentication. Session
identification.
- Confinement:
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?
Ambient
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
wrong).
- 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.
- Collections:
Of related or interdependent resources. Widgets.
- Resource management:
Installation, offline storage (client-side databases?)