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
- How to specify whether a field is optional or required?
Anchor Design Pattern
<a class="deth" href="http//somesite.com/prog/adduser">label</a>