rest/rex-proposal

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

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