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

2. 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?

3. 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”

4. 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

5. 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

6. 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.

7. 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?