Web Architecture update for WSAWG/WSDL

Slide image generated by PowerPoint
TAG published Principles of the Web
Contents:
Identifiers
Most of the work
Formats
Not much
Protocols
Summary of REST so far

Identifiers

Slide image generated by PowerPoint
URIs are it
Should Use Absolute URI
Uses of URIs:
Comparison
Example use case, SOAP Actor/Role
Open issue, but generally comparison is scheme specific.
Interaction (called Dereferencing)
Retrieve a Representation
Others
Make sure URIs are persistent
QNames in content are OK as well
TAG provides no guidance on when to use QNames vs URIs
Big huge ugly issue: What is range of http: URI schemes?  People?

Protocols (REST)

Slide image generated by PowerPoint
REST is Representational State Transfer
"REST provides a set of architectural constraints that, when applied as a whole, emphasizes scalability of component interactions, generality of interfaces, independent deployment of components, and intermediary components to reduce interaction latency, enforce security, and encapsulate legacy systems"

Basics of REST: Constraints

Slide image generated by PowerPoint
Client/Server: separate data from control logic
General good practice, also in web arch doc formats section
Stateless Protocols
All the data sent in each request
Caching
Uniform Interface
Layering
Dependency of component is to next component
Optional Code on demand

Basics of REST: Architectural Components

Slide image generated by PowerPoint
Data Elements
Resource, Resource Identifier, Representation, Representation metadata(ie media-type), resource metadata(ie. alternates), control data
Connectors
Client, Server, Cache, Resolver, Tunnel
Components
User Agents, gateways, proxies, origin servers

Uniform Interface

Slide image generated by PowerPoint
Subtitled: Let the games begin
The principle of REST is that GET/POST/PUT/DELETE are the interaction "verbs"
Rationale:
By fixing the verbs, firewall admins/app developers/software has predictable constraints.
This increases dramatically the ability of software to interact with resources in an ad-hoc manner.
You can ALWAYS GET a URI
Performance benefits: no need for firewall to crack the body
Further, the application knows all about the interactions
Reliability, choreography, etc. are at the app level
You can't hide these or layer them from the app.

Some questions and personal opinions:

Slide image generated by PowerPoint
REST compliance required for web architecture?   Technical/Political
Embedding "procedure names" in SOAP bad?
Current TAG finding says GET on important resources is sufficient
Can the Web Architecture have more than 1 architecture?
Where is REST(HTTP?) current broken and can WS help?
Is the REST interaction model useful for what we want with Web Services?
REST's hypertext origins, new requirements and advent of XML
IMO, XML and machine/machine breaks the whole thing open
What about web sites that don't follow REST?
IMO, most sites intermix GET/POST and don't use PUT/DELETE
And they use stateful interactions (session IDs)
SOAP 1.2 Binding Framework uses HTTP "well", isn't that sufficient?
Has REST helped or hurt machine to machine communications?