Web Architecture update for WSAWG/WSDL
|
|
|
|
|
TAG published Principles of the Web |
|
Contents: |
|
Identifiers |
|
Most of the work |
|
Formats |
|
Not much |
|
Protocols |
|
Summary of REST so far |
|
Identifiers
|
|
|
|
|
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)
|
|
|
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
|
|
|
|
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
|
|
|
|
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
|
|
|
|
|
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:
|
|
|
|
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? |
|