The most recent, and recommended, format for discovery is XRD (currently at Working Draft 15). XRD supersedes the older XRDS format, which has a convoluted evolution that can be traced in twists and turns through XRI Resolution, Yadis, and XRDS-Simple.

These older specifications define both a data format and a resolution protocol. The resolution protocol suffers a problem, however: it can’t distinguish between a host and a root-level resource. A succinct technical statement is provided in Eran Hammer-Lahav’s host-meta draft:

Because there is no URI or a resource available to describe a host,
many of the methods used for associating per-resource metadata (such
as HTTP headers) are not available. This often leads to the
overloading of the root HTTP resource (e.g. ‘http://example.com/’)
with host metadata that is not specific to the root resource (e.g. a
home page or web application), and which often has nothing to do it.

Take, for example, http://jaredhanson.net/, the URL I use to identify myself online. It has an XRDS document located at: http://jaredhanson.net/meta.xrds

<xrds:XRDS xmlns:xrds="xri://$xrds"
           xmlns="xri://$xrd*($v*2.0)">
<XRD>
  <Service>
    <Type>http://portablecontacts.net/spec/1.0</Type>
    <URI>http://www-opensocial.googleusercontent.com/api/people/</URI>
  </Service>
  <Service>
    <Type>http://specs.eaut.org/1.0/template</Type>
    <URI>http://jaredhanson.net/</URI>
  </Service>
</XRD>
</xrds:XRDS>

Among the services advertised are an address book available via Portable Contacts and an EAUT-based email address to URL translation service. The address book is very specifically associated with me; it is my address book. The EAUT service, however, is simply a service that is running at the domain jaredhanson.net; it is not associated with me directly. This case exhibits the conflict between the host and the root-level resource.

The new XRD specification does not define a resolution protocol. That task is left up to other specifications such as host-meta and LRDD. host-meta, in particular, addresses this conflict by registering a well-known URI for metadata about the host.

Looking again at my digital identity, things have been broken down into two separate documents. One for information about the host at: http://jaredhanson.net/.well-known/host-meta

<XRD xmlns="http://docs.oasis-open.org/ns/xri/xrd-1.0"
     xmlns:hm="http://host-meta.net/xrd/1.0">
  <hm:Host>jaredhanson.net</hm:Host>
  <Link rel="lrdd" template="http://jaredhanson.net/meta.xrd?id={uri}"/>
</XRD>

And another for information about me at: http://jaredhanson.net/meta.xrd

<XRD xmlns="http://docs.oasis-open.org/ns/xri/xrd-1.0">
  <Subject>acct:me@jaredhanson.net</Subject>
  <Link rel="http://portablecontacts.net/spec/1.0" href="http://www-opensocial.googleusercontent.com/api/people/"/>
</XRD>

Using this schema, my address book remains in the XRD that describes me. However, WebFinger (the modern EAUT equivalent), which utilizes LRDD, moves to the host-meta XRD. This is a much cleaner approach, which resolves ambiguities about exactly what discovery is being performed on.

Content, as a concept, encompasses a wide area. It could be a newspaper article, a radio program, a TV show, a spreadsheet or presentation. Creating and managing content has been one of the primary purposes of computers, ever since they came into existence.

With the rise of the Internet, and particularly social networking, there has been a renewed focus on people and the role they play in a system. Proper emphasis on individuals and groups makes collaboration more efficient.

One of the problems surrounding identity in the past has been the lack of a widely adopted standard. This has made it very difficult to build solutions that are interoperable. Thankfully, OpenID is gaining traction, along with usability improvements through EAUT and other initiatives.

Underlying OpenID, the XRD specification, emerging from earlier work on XRDS-Simple and Yadis, will tie people and content together through services that allow interaction among the two.

There is a lot of work remaining, but its conceivable at this point to envision a future where signing up for a service is as simple as entering your email address and approving access. When the mesh realizes that level of usability, innovation will both flourish and be self-reinforcing.

Developers would be well advised to pay attention to these standards. Integrating these technologies will allow software to participate in the larger web-based ecosystem, both deriving and yielding benefits from and to the whole.

As I noted in my comment:

The standards are all coming together. In my mind, the flow looks something like this:

1. People become directly addressable (i.e. through email addresses).
2. Programs dereference the email address and get an XRD document, which identifies associated services.
3. Programs interact with the discovered services to publish and subscribe to content.

Upon first seeing the spec, I immediately tweeted:

oEmbed completely ignores REST principles. GET with a Content-Type to the original resource. Benefit: a single URL per resource. C’mon!

Allow me to further explain…

To begin with, let’s dive into the specification, and take note of the things that immediately raise red flags.

An oEmbed exchange occurs between a consumer and a provider. A consumer wishes to show an embedded representation of a third party resource on their own web site, such as a photo or an embedded video. A provider implements the oEmbed API to allow consumers to fetch that representation.

Hmm… that sounds suspiciously like an HTTP GET request. Why the need to refer to this as “the oEmbed API”?!? Something suspect must be about to go down.

Configuration for oEmbed is very simple. Providers must specify one or more URL scheme and API endpoint pairs. The URL scheme describes which URLs provided by the service may have an embedded representation. The API endpoint describes where the consumer may request representations for those URLs.

Wait… what? This oEmbed thing requires two URLs to fetch different representations of the same resource? Have we not learned even the most rudimentary REST principles in the past few years? Here’s a quick lesson: a single resource can have multiple representations. One URL, multiple data formats. Once that is understood, the need for an oEmbed API endpoint drops away entirely.

Even so, let’s be pragmatic and use oEmbed, since some respectable providers have already implemented support for it. (Which begs further questions, but I’ll let that slide.) To start, we need to get the address of the API endpoint. That mechanism is not specified, so we’ll have to resort to hardcoding endpoints. XRDS could be useful here, but that introduces further complications. Besides, there is better way.

oEmbed with REST to the Rescue!

Since the URL to the original resource must be known, and an oEmbed representation is desired, the oEmbed API endpoint is completely unnecessary. Just request the oEmbed representation from the resource directly.

GET /photos/bees/2362225867/ HTTP/1.1
Host: flickr.com
Accept: application/oembed+xml


Flickr could then respond with our embed-ready resource.

HTTP/1.x 200 OK
Content-Type: application/oembed+xml
 
<oembed>
<version>1.0</version>
<type>photo</type>
<title>Bacon Lollys</title>
<author_name>bees</author_name>
<author_url>http://www.flickr.com/photos/bees/</author_url>
<cache_age>3600</cache_age>
<provider_name>Flickr</provider_name>
<provider_url>http://www.flickr.com/</provider_url>
<width>500</width>
<height>375</height>
<url>http://farm4.static.flickr.com/3040/2362225867_4a87ab8baf.jpg</url>
</oembed>


See that! There is absolutely zero requirement for the oEmbed API. All we need to do is define a couple data formats and the associated MIME types. While there is evidence of duplicative effort, the oEmbed formats look reasonable and have both XML and JSON output. I propose we define them as application/oembed+xml and application/oembed+json.

Error handling is equally trivial. If support for RESTful oEmbed is not implemented, a standard HTTP 406 Not Acceptable status code would be returned to the client. The client could then fail over to screen scraping or proprietary APIs as necessary.

I hope I’ve outlined my case against oEmbed effectively. If anyone has any questions or concerns, drop a line in the comments.