70 likes | 261 Views
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
E N D
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?