Difference between revisions of "rest/rex-proposal"

From Microformats Wiki
Jump to navigation Jump to search
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 & POST (not PUT or DELETE)
** Just GET
** 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
  <div class="org">Technorati</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>
= 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
** research: http://microformats.org/wiki/rest-examples
** blog: http://www.opendarwin.org/~drernie/
** This presentation: http://microformats.org/wiki/rex-proposal-preso

Revision as of 18:21, 22 June 2007


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
    • URIs are method names
    • XML is the arguments format
    • Implemented in XML-RPC and SOAP
  • REST: Representational State Transfer
    • Nouns are URIs, verbs are HTTP: GET, PUT, POST, DELETE
    • XML documents are state information
    • Implemented at Atom, Amazon (sorta)

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