rest/rex-proposal: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
m (Reverted edits by BobotRocla (Talk) to last version by Tantek) |
||
(2 intermediate revisions by 2 users not shown) | |||
Line 58: | Line 58: | ||
* Subset of REST that works with browsers | * Subset of REST that works with browsers | ||
** XHTML Basic vs. arbitrary XML | ** XHTML Basic vs. arbitrary XML | ||
** Just GET | ** 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 | |||
= Three Challenges = | |||
* 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, "[http://tantek.com/presentations/2005/06/what-are-microformats/ 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 | |||
** [http://microformats.org/wiki/hcard hCard] (based on [http://www.ietf.org/rfc/rfc2426.txt vCard]) | |||
** [http://microformats.org/wiki/hcalendar hCalendar] (based on [http://www.ietf.org/rfc/rfc2445.txt iCalendar]) | |||
* Data structures | |||
** [http://microformats.org/wiki/xoxo XOXO] lists: ol, ul, dl | |||
** [http://microformats.org/wiki/table-examples XOXT] tables: th, tr, td | |||
= Example: hCard = | |||
* ''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 [http://developer.apple.com/documentation/Cocoa/Conceptual/PropertyLists/Concepts/XMLPListsConcept.html 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. [http://www.rubyonrails.org/ 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 = [http://en.wikipedia.org/wiki/Pareto_principle 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 | |||
** cf. [http://intertwingly.net/slides/2005/rs/ Radical Simplification] | |||
= Advantages = | |||
* 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 | |||
= Implications = | |||
* Is this the "[http://www.gladwell.com/tippingpoint/ tipping point]"? | |||
** The 'LDAP' of web services? | |||
** The 'missing link' for REST? | |||
** The 'killer app' for Ruby on Rails? | |||
* Why? | |||
** 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 | |||
** Microformats Information: http://mydatapages.com/microformats.html | |||
* XHTML and REST | |||
** research: http://microformats.org/wiki/rest-examples | |||
** blog: http://www.opendarwin.org/~drernie/ | |||
** This presentation: http://microformats.org/wiki/rex-proposal-preso |
Latest revision as of 22:38, 20 December 2008
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
- Discoverability
- No standard way to find services
- Interoperability
- Too many incompatible ways to encode links, data
- Extensibility
- What if your schema isn't 100% right?
- Comprehensibility
- 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
Three Challenges
- 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
Example: hCard
- 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
Advantages
- 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
Implications
- Is this the "tipping point"?
- The 'LDAP' of web services?
- The 'missing link' for REST?
- The 'killer app' for Ruby on Rails?
- Why?
- 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
- Microformats Information: http://mydatapages.com/microformats.html
- XHTML and REST
- research: http://microformats.org/wiki/rest-examples
- blog: http://www.opendarwin.org/~drernie/
- This presentation: http://microformats.org/wiki/rex-proposal-preso