From Microformats Wiki
Revision as of 19:50, 13 October 2005 by DrErnie (talk | contribs) (=== Nouns ===)
Jump to navigation Jump to search

XHTML-REST Brainstorming

This page collects ideas from rest/examples how to best encode REST data in an XHTML microformat.


The underlying premise of this investigation is that REST is less useful that it could be due to concerns about a) interoperability, and b) discoverability. To address this, we propose adopting microformat-style conventions to further constrain the ways REST already constrains web services.

In particular, we constrain REST to work with existing web browser clients -- yet also be machine-parseable. This means:

  • All inputs must be url-encoded (or maybe mime/multipart)
  • All output must be XHTML, either:
  • All URI links must be encoded as either:
    • Anchors (<a&rt;) (via 'href')
    • Forms (<a&rt;) (via 'action')
  • Only GET and POST actions are supported

This may seem very strict, but that's the point: by adding more constraints, we reduce gratuitous degrees of freedom and enable greater consistency.

This may not solve every conceivable problem, but it should handle the 50% case pretty well:

  • REST: 80% of web services
  • XHTML: 80% of XML expressiveness
  • GET/POST + urlencoding: 80% of queries

or, put another way:

  • 80% x 80% x 80% = 51.2% of the benefit for
  • 20% x 20% x 20% = 0.8% of the effort


To make parsing and auto-discovery easier -- and also simplify the design process -- we propose the following additional conventions.


As usual in REST, every noun must be a URI. However, we explicitly define four types of URIs:

root;The base URI for the web service, e.g.:
instances;URIs representing individual entities, e.g.:
factories;The URIs used to create or search for those instances, e.g.:
singletons;Any URIs instances that are not part of a particular factory, e.g.:


Questions for further research

  1. How to specify whether a field is optional or required?


Anchor Design Pattern

<a class="deth" href="http//">label</a>

Forms Design Pattern

See Also

Proposed REST API