This project is read-only.

Resource Accessible Via File URI ("/{id}.png")

Topics: Web Api
May 27, 2011 at 2:49 AM
Edited May 27, 2011 at 3:34 AM

I think it would be really nice if a resource was accessible as a file Uri  (i.e. /Resource/{id}.png, /Resource/{id}.ics) as well as (maybe instead of) how they are accessed currently (/Resource/{id}/png, /Resource/{id}/ics) . To me, it seems much more intuitive and in the spirit of REST to access a resource that way. "/png" looks like a directory. Sorry if this has been brought up before, if so, I couldn't find it.

May 27, 2011 at 4:53 AM

Hi Jason

I understand what you are asking for.

First I want to clarify that it has nothing to do with being RESTful.  URIs have nothing to do with REST. From a REST perspective URIs are opaque. A resource can be anything, and does not have to be a file. Ideally clients should know nothing about how to create URIs in your system. Any knowledge they have to the URI space couples them to your system thus preventing evolvability something core to REST.

You can have URIs to a representation but they are bookmarks only. The URI might as well be a guid. It can and should have meaning to the server. That URI can literally be any format, it can use slashes, dots, exclamation points whatever. The important thing is that the server controls it's creation and the client is not coupled to it. The client should view it as opaque.

Now on to you original question:

Whether you use a dot or a slash is completely a matter of preference, and you are definitely free to do it.

In the case of why I chose to do a "." here as opposed to a slash. It was a very practical reason. When you model resources you commonly have collection resources and item resources. Supporting an item resource of the form /Resource/id.png can work fine with our hosting because I can specify "Resource" as the base address and have an {id} param for the resource uri template.

Supporting the same on a collection resource however doesn't appear to work as you can't put parameterization in the base address to match on a '.' + extension. If you put the . in the uritemplate of the collection it assumes it is after a slash, thus you end up with "/Resources/.png" for the extension.

Because of not finding an easy way to get that to work (yes it was my initial preference) combined with the fact that REST doesn't care, I chose the "/".




May 27, 2011 at 3:06 PM

I shouldn't have said "in the spirit of REST", especially since I just called someone out yesterday for making the same mistake. I'm getting myself caught up in the buzz word mass confusion :)

Looks like we're on the same page with the idea. I see how it's possible to pull off {id}.ext with a little extra work but I also ran into the same issue with the URI template making collection resources "/.ext" which is super ugly. "/ext" seems as good a syntax as any. IMO, it's definitely better than ?format=.

On May 26, 2011 11:53 PM, "gblock" <> wrote: