RE: URI Templates - optional variables?

Roy T. Fielding wrote:

> Easy to read by whom?  I went through the readable bits with 
> HTTP and it turned out to be a big mistake.  Nobody reads 
> HTTP in real practice, yet the overhead of parsing HTTP 
> messages is huge.
> 
> I think of URI templates as a generalization of 
> server-provided info on how to construct the URI for a 
> resource space, in the same way that server-side image maps 
> defined a constructor for map points.
> I think the main use case is going to be within the Link (or 
> was it Link-Template?) header fields, which means they will 
> be protocol bits and reducing the length of those bits will 
> be important.

That's a sadly limited vision, especially from you Roy, for a technology
that can address why so many people violate the RESTian principle of
"Hypermedia being the engine of application state." 

Assuming they are ultimately specified to be non-cryptic and approachable, I
envision URI Templates to become as commonly used as technologies like URIs,
HTML, and CSS, not just something arcane that only gereks use in link header
fields.

The first place I envision URI Templates to proliferate, if they are
approachable, is in content management systems.  Many content management
systems (such as Drupal) give administrators the ability to define paths
using templates, and URI Templates would be the perfect specification to
unify all those varied and number proprietary URL template languages.

In addition, once URI Templates are used in content management systems it
would be a small step to expose them in HTML <link> and <meta> tags allowing
client agents to process them. This could unleash an entire new wave of web
service functionality as URI Templates are used in ways this small group of
mailing list subscribers can't even dream of.

Still more, if URI Templates are approachable they can be composed into
technologies such as HTML Forms:

http://blog.welldesignedurls.org/2007/01/11/proposing-uri-templates-for-webf
orms-2/ 

Beyond that I can easily see URI Templates proliferate in all manners of XML
documents; any XML document where a URI has value there is a great chance a
URI Template will have value. Once such example is in Flex MXML files. The
average person coding in Flex is definitely not your most technical gear
head, they typically evolve from graphic design, and those people will
benefit from an approachable URI template spec.

Beyond even that, I see URI Templates as being an excellent (if
approachable) and sorely needed language for documenting URI spaces. I
already use if for such. However, if URI Template syntax becomes so cryptic
that few can comprehend them then URI Templates will by definition not be
use for documenting URI spaces which will be a huge shame because then
people will document them in other non-standard and non-compatible ways.

> I want templates to be easy for a computer to read and easy 
> for a computer to generate from that reading a 
> fully-descriptive page of information in the user's favorite 
> language.  For example, define a web service that inputs a 
> template and outputs the readable description according to 
> the Accept-Language received.

And I want URI Templates to be easy for a human to read and easy for a human
to write, for all the reasons I specified above, and more, as they are just
the tip of the iceberg. I see no reason why if we put our heads to it we
cannot achieve both goals: human and computer processable.

So please don't attempt to hide URI Templates in only HTTP headers as only
very technical people every see those HTTP headers. However, an increasingly
larger segment of the population sees and hence authors the respresentations
returned by resources, AKA HTML, XML, etc. To paraphrase an old chestnut,
"When the only tool you consider is HTTP, everything looks like a header."
If we make URI templates approachable and editable by humans it will take us
closer to REST nirvana.

-- 
-Mike Schinkel
http://www.mikeschinkel.com/blogs/
http://www.welldesignedurls.org
http://atlanta-web.org

Received on Tuesday, 16 October 2007 19:49:24 UTC