Danny Ayres recently posted some podcasts whose resources don’t include file-type extensions. Now I use a greasemonkey script that parses for resource extensions and displays icons (or embeds a flash player) next to them. Great for finding media links when scanning pages. This had me wondering; should all resources include Content-Type in the URI instead of or in addition to HTTP headers?

When a file-type extension is provided, HEAD requests for every single link to find their Content-Type isn’t then required. Some pages I load, include thousands of links(my news aggregator). A thousand HEAD requests doesn’t sound fun.

When I think about objects I see in the real world, the first thing my mind tries to figure out based on the context in which I find it is the type of object I’m looking at or feeling, and if it’s a type that interests me.

Online for me this translates into the context being the URI, and the type the extension. Therefore it makes sense to me to always include an extension.
If on the other hand I want to take a close look at an object (or resource) then I pay closer attention to it (obtain it or its metadata).

Saying that, it also makes sense to include things like geospatial information in the context. eg. date, location.
What brings me to the who, what, where, when, how and why of resources.

who owns the resource, what is the resource, where does it relate to, when was it made, how you interact with it, and the why is the data, which is self explanitory.

http://example.com/category/2007/May/21/a-new-resource.html

Or, written as an XRI:

=examplewho+tagwhere$date*2007-05-07/what-this-is$type*text-html

Though I’m unsure as to whether you can have the $type listed after a directory symbol. If you can, think about a resource with multiple URIs describing that resource. Mix and match those context symbols with alternate descriptions or locations and you’ve exposed large amounts of metadata about a resource. e.g;

=who/my-image$imgsize*100×100$type*png
=who/my-image+car+burnout+night
=who/my-image$copyright*cc-sharealike

what about using a third-party service to do a conversion.

@convertercompany=who/my-image.jpg$imgsize*10×10$type*image*png

Alex Barnett asks about Web Description Languages for REST. Below is a simple example of my own interpretation based originally upon WADL, something I worked on and never did anything with some months ago. It follows the philosophy of least amount of validation, user and machine readable documentation and graceful depreciation. I got so far as to consider re-writing it as a microformat before I became lost in the concept that was the HTTP Extensions Framework (PEP).

Now I love the idea of having the ability to query a resource to find method queries with documentation I can use to interact with that resource. It’s here I believe a WDL may come in very useful. I say may because I wonder if resources themselves should have a Resource Description Language instead.

One of the problems I have with PEP is that pointing to some external language as it enables, adds another layer of fragility. It’s resources themselves that need to contain everything required to interact with that resource. Have a listen to Alan Kaye’s talk for a better explanation.

So using REST I would then simply perform a

GET / HTTP/1.1
Accept: xml/rdl
Host: example.com

Whereby something like my AWDL example is returned. It could however be an HTTP Form, microformat or XForm returned.
[xml]

xsi:schemaLocation="http://example.com/awdl awdl.xsd"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://example.com/awdl">

Update: http://www.w3.org/Protocols/PEP/ does what I'm looking for.
I'm throwing this half-baked idea out there for some feedback to see how feasible it might be.
It's basically extending HTTP with directional URI-namespace methods. URI specfic methods could be looked up by a client with HTTPs OPTION method. The returned Allow: response then used to determine what API methods can be performed on any particular resource. URI Namespacing them would allow anyone to create their own documented API that could be looked up manually or auto-discovered and documented with crawlers.

Method naming would indicate in which direction messages are passed with just the .POST and .GET (Input/Output) suffixes? doing away with PUT and DELETE and other keyword methods in favour of directional URI name space methods. Stateless producer/consumer.

eg:

Resource Methods Introspection:

Request:

OPTIONS /people/person HTTP/1.1
Host:example.com

Response:

Allow: GET, POST, OPTIONS, xmlns.com/foaf/0.1/Person.GET, xmlns.com/foaf/0.1/Person.name.POST
In this example the foaf:name documentation section of the spec could be returned on sending a GET to the "http://xmlns.com/foaf/0.1/Person.GET" URI. Or the "xmlns.com/foaf/0.1/Person.GET" method could be called on the resource that returned it, for example:

Request:

xmlns.com/foaf/0.1/Person.GET /people/person HTTP/1.1
Host: example.com

Response:

<foaf:Person>

<foaf:name>Craig</foaf:name>
<foaf:homepage rdf:resource="http://example.com/blog/"/>

</foaf:Person>

Say you wanted to update the foaf:name element for http://example.com/people/person you might use a method that looks like this:

Request:

xmlns.com/foaf/0.1/Person.name.update.POST /people/person HTTP/1.1
Host: example.com

<foaf:name>ENDOVER Craig</foaf:name>

Response:

HTTP/1.1 200 OK
Date: Mon, 20 Nov 2006 14:30:17 GMT

<foaf:name>ENDOVER Craig</foaf:name>

Delete a Person like so:

xmlns.com/foaf/0.1/Person.delete.POST /people/person HTTP/1.1

Performing a straight GET on http://example.com/people/person could return an entire blog whereas the foaf:name method call just returns a the blog owners foaf.

Consider other APIs and a different syntax:

microformats.org/URImethods.hCard.FN.POST /people/person HTTP/1.1
microformats.org/URImethods.hCard.URL.POST /people/person HTTP/1.1
w3c.org.SPARQL.1_0.endpoint.GET /people/person HTTP/1.1
w3c.org.OWL.sameAS.GET /people/person HTTP/1.1
w3c.org.OWL.sameAS.POST /people/person HTTP/1.1

Annote the semantic web?

One thought is that GET/POST may not be ideal. eg. Benjamin Carlyle's SENA internet draft comes to mind

Consumer:
soundadvice.id.au.SENA.SUBSCRIBE.POST
soundadvice.id.au.SENA.NOTIFY.GET
soundadvice.id.au.SENA.NOTIFYPATCH.GET
soundadvice.id.au.SENA.EXPIRE.GET

Producer:
soundadvice.id.au.SENA.SUBSCRIBE.GET
soundadvice.id.au.SENA.NOTIFY.POST
soundadvice.id.au.SENA.NOTIFYPATCH.POST
soundadvice.id.au.SENA.EXPIRE.POST

INBOX / OUTBOX may be a better choice?

Consumer:
soundadvice.id.au.SENA.SUBSCRIBE.OUTBOX
soundadvice.id.au.SENA.NOTIFY.INBOX
soundadvice.id.au.SENA.NOTIFYPATCH.INBOX
soundadvice.id.au.SENA.EXPIRE.INBOX

Producer:
soundadvice.id.au.SENA.SUBSCRIBE.INBOX
soundadvice.id.au.SENA.NOTIFY.OUTBOX
soundadvice.id.au.SENA.NOTIFYPATCH.OUTBOX
soundadvice.id.au.SENA.EXPIRE.OUTBOX

This all seems feasilble to me but I'm only just getting my feet wet with HTTP, so feedback would be greatly appreciated.

Craig.