Jump to navigation Jump to search
Revision as of 23:58, 19 October 2005 by DrErnie (REX (was DUHPER) - thanks to Stephen Downes for the name)
- 1 REX: REST-Enabled XHTML
- 2 What is REX?
- 3 Web Services: The Opportunity
- 4 Web Services: The Problem
- 5 The Answer(?): REST vs. RPC
- 6 Advantages of REST over RPC
- 7 Challenges of REST
- 8 Proposal: A Dual-Use (X)HTML Profile
- 9 Three Challenges
- 10 Challenge #1: Machine-Parseability
- 11 What Are Microformats?
- 12 Kinds of Microformats
- 13 Example: hCard
- 14 Example: eXtensible Open XHTML Outlines
- 15 Challenge #2: Only Two Verbs
- 16 Challenge #3: Key-Value Data
- 17 The 0.8% Solution for Web Services
- 18 Advantages
- 19 Implications
- 20 For More Information
REX: REST-Enabled XHTML
The 0.8% Solution for Web Services
October 19th, 2005
What is REX?
- "Design Pattern" for Web Services
- Architectural approach
- Not a specific technology implementation
- cf. DHTML, AJAX, REST, etc.
- Specific profile for REST
- XHTML microformats as the data format
- Browser-compatible invocations
- Human-friendly conventions
- Trivial to implement with existing tools
Web Services: The Opportunity
- "The Next Big Thing"
- Rewriting the web as a platform
- Foundation of [Web 2.0] businesses
- Architecture of participation
- Infrastructure for collaboration
- Enterprise App Integration (EAI) all over again
Web Services: The Problem
- Can work really well when you have:
- Well-defined community
- Well-run governance
- Well-understood problem space
- Not true of the public Internet
- Not true of most vertical industries
The Answer(?): REST vs. RPC
- RPC: Remote Procedure Calls
- REST: Representational State Transfer
Advantages of REST over RPC
- Much simpler to design
- Easy to identify appropriate nouns
- Don't need to define methods (verbs)
- Don't need a complete object model
- Easier to learn/invoke
- Always know what a URI means
- Need not 'tunnel' XML inside XML
Challenges of REST
- No standard way to find services
- Too many incompatible ways to encode links, data
- What if your schema isn't 100% right?
- What the heck does "state transfer" mean?
Proposal: A Dual-Use (X)HTML Profile
- Subset of REST that works with browsers
- XHTML Basic vs. arbitrary XML
- Just GET & POST (not PUT or DELETE)
- Encode URIs in hyperlinks (<a href>) and forms (<form action>)
- Inputs always key-value pairs (like database table)
- With CSS and AJAX, can be the website
- DRY = Don't Repeat Yourself
- Makes discovery and documentation trivial
- Is HTML Machine-Parseable?
- Are there really only two verbs?
- Can you build real apps on key-value encoding?
Challenge #1: Machine-Parseability
- Screen scraping all over again? No!
- Use the "secret sauce" of "semantic salt"
- cf. "syntactic sugar" -- hides unpleasant details
- "semantic salt" -- brings out latent structure
- In other words, "microformats"
What Are Microformats?
- simple social conventions (rel="profile")
- using existing tags or brief CSS class names
- to encode machine-readable semantics
- in human-readable HTML, XHTML, or even XML
- cf. <link rel> in Atom
Kinds of Microformats
- Link annotation, e.g.:
- RelTag (Technorati): <a rel="tag" href=...>
- RelNoFollow (Google): <a rel="nofollow" href=...>
- User data
- Data structures
- hCard class names := vCard fields
<div class="vcard"> <a class="url fn" href="http://tantek.com/"> Tantek Çelik </a> <div class="org">Technorati</div> </div>
Example: eXtensible Open XHTML Outlines
- Reuse existing HTML tags
- Arbitrary data structure (like property lists)
<dl class='xoxo'> <-- Dictionary --> <dt>Key #1<dt> <dd><ol> <-- Array --> <li>sub-item #1</li> <li>sub-item #2</li> </ol></dd> </dl>
Challenge #2: Only Two Verbs
- Overload URI with actions? No!
- Web 2.0 is an constructive medium
- Don't store a document; ask for creation
- POST parent&key1=value1 => child URI
- Don't overwrite documents; update
- POST child&key1=value1 => new child URI
- Don't delete a document; flag for removal
- POST child&shouldDelete=true
Challenge #3: Key-Value Data
- Encode complex structures as XML text? No!
- Treat web service like a database
- Common classes (e.g. users, items, carts) => tables
- Key-value dictionaries => records
- URIs for each records => primary keys
- Need NOT reflect actual internal database
- Can present a synthetic view
- But, makes a great starting point (cf. Ruby on Rails
The 0.8% Solution for Web Services
- (80% of benefit/20% of effort)^3
- XOXO vs. XML: 80/20
- GET/POST vs. REST: 80/20 x 80/20 = 64/4
- Key-Value vs. structured input: 80/20 x 64/4 = 51.2/0.8
- Half the benefit for 1% of the effort!
- Maybe not everything, but the basics easily
- Power comes from how much you can ignore
- Reuse existing semantics and structure
- Generally only one way to encode something
- Reduce possible degrees of freedom
- Simplifies design, improves interoperability
- Focus on the 80% where agreement is easy
- Increase learnability
- Everyone (in this space) can write it
- Everything (in the world) can read it
- The API is the documentation is the format
- Is this the "tipping point"?
- The 'LDAP' of web services?
- The 'missing link' for REST?
- The 'killer app' for Ruby on Rails?
- Looser than XML => allows innovation
- Tighter than REST => encourages interoperability
- Simpler than SOAP => enables rapid adoption
For More Information
- Microformats http://microformats.org
- What are Microformats? http://tantek.com/presentations/2005/06/what-are-microformats/
- Discussion Lists http://microformats.org/discuss/
- XOXO: http://microformats.org/wiki/xoxo
- XHTML and REST