From Microformats Wiki
Jump to navigation Jump to search


The purpose of this presentation is to describe and justify a proposal for using microformants to constrain REST implementations.

Web Services: RPC vs. REST

  • 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/SOAP

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

Solution, Part I-A: XHTML

  • Use XHTML Basic instead of XML
  • Don't need a rigid schema
  • No namespaces; free to extend as needed
  • Everyone (in this space) can write it
  • Everything (in the world) can read it

Solution, Part I-B: XHTML Microformats

  • microformats: Add 'semantic salt' to XHTML
    • Annotate existing XHTML tags with meaning
    • Machine-parseable yet human-readable
  • Links as <a href=> and <form action=>
  • Lists as XOXO: eXtensible Open XHTML Outlines
  • CSS classes to reflect semantics

Solution, Part II: Browser clients

Solution, Part III-A: Web as database

  • CRUD: Create, Retrieve, Update, Delete
  • Structured URLs vs. Opaque URIs
  • Note: need not reflect actual database
    • Synthetic "user model" for public API purposes
    • But, an easy way to start (cf. Ruby on Rails)

Solution, Part III-B: Web as database

  • base: defines service
    • GET base?query # search across all tables
  • table: collection of URLs with same schema
    • GET table?query # search across this table
    • URIs become primary keys for joins!
  • record: individual item, user, cart, etc.
    • POST table?data # update record

Solution, Part III-C: Web as database

The 0.8% Solution for Web Services

  • (80% of benefit/20% of effort)^3
    • XHTML vs. XML: 80/20
    • GET/POST vs. REST: 80/20 x 80/20 = 64/4
    • Database vs. freeform URIs: 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


  • The 'missing link' for REST?
  • The 'killer app' for Ruby on Rails?
  • The "tipping point" for web services?
    • Looser than XML => easier compatibility
    • Tighter than REST => better interoperability
    • Simpler than SOAP => greater adoption

Examples (TBD)

  • ?view=api (dictionary of valid requests)
  • {base,table}?query (OpenSearch)
  • base/ (home page)
  • table/ (section page)
  • table?view=edit (record creation forms)

Examples - Records (TBD)

  • record/ (default view)
  • record?view=edit (record update)
  • record?view=list (dt/dd list)
  • record?view=table (th/td row)

But Wait, There's More!

  • Not just for web services
    • Do your whole website this way!
    • CSS classes + styles => prettified XHTML
    • Don't Repeat Yourself (DRY): website == API
  • Perfect solution for AJAX
    • AJAX: Asynchronous-JavaScript-and-XML
    • Actually, JAH: Just Asynchronous HTML
    • JavaScript loves HTML; fast, only eight lines of code!

For More Information