Download Berlin Overview (WLI 2.1)

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:
•••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••
1. 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?
2. Where is REST(HTTP?) current broken and can WS help?
3. 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
4. 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)
5. SOAP 1.2 Binding Framework uses HTTP “well”, isn’t that sufficient?
6. Has REST helped or hurt machine to machine communications?