« May the goodbye be longLines of code »

URL's are files, again, apparently

07/17/07

Permalink 08:00:30 am, by fumanchu Email , 38 words   English (US)
Categories: IT, Python

URL's are files, again, apparently

It doesn't try to reinvent web files as classes. URLs retain their meaning as file locations.

Best example of Not Getting It I've seen in a while. Somebody needs to re-read Fielding.

5 comments

Comment from: Maciej [Visitor]

Could you please explain?

07/17/07 @ 08:36
Comment from: Simon Davy [Visitor]

Maciej:

The referenced post describes a web framework (Wasp) that directly maps web urls onto directories and files on a hard disk. This is the traditional way in which websites are built, with static html files, or php files, for example. So the url http://site.com/people/simon.html would look for the file "simon.html" in the directory "people" on whatever machine is serving http://site.com. Is simple, it works, but with some big limitations, especially for sites with dynamic resources. It is however, the way many people understand the way websites work.

However, this direct mapping of url-to-file, including file extension, is a limited (and incorrect) interpretation of the concept of a resource (which is what a url describes : Universal Resource Locator). This is discussed in Roy Fielding's PhD thesis[1], hence FuManChu's reference. A url should really represent a resource of some kind, of which a variety of representations/actions can be requested/performed. To continue the above example, the url http://site.com/people/simon could be a reference a resource about me. Notice the lack of a .html file extension. I can request a representation of that information as a html page, for example. This is then default for browsers. Or I could ask for XML (if I were a web spider or other computer, for example). Or JSON, RSS, csv, word, excel, jpeg, or whatever the server supports. I can also, via a slightly different request to the same url, update the information or delete the resource altogether (assuming I have permission to do so). All this is possible over plain old HTTP.

IMO, url-to-file path mapping has its uses for simple, static sites, but nearly all mine use a framework that allows more useful mapping of urls to resources.

HTH
[1] http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

07/17/07 @ 09:57
Comment from: bignose [Visitor]

Or, more succinctly: URLs don't "retain their meaining as file locations", because that was never their meaning. Sometimes file locations were a convenient mapping for URLs, but that was never their primary "meaning".

07/18/07 @ 03:19

I am the original author and I do get it. The comment here takes a one-liner from my article way out of context. The article is not a treatise on RFCs or web protocols, it is a quick summary of features of a tool in progress. In other words, it is not theory but practice.

That the traditional interpretation of an URL is a pointer to a file on a network is hard to deny. That's why if you look on a web server in /var/www/htdocs (or wherever) you will find files... 99.9% of the time.

And for many it is easier to keep working with URLs that way. That's all I was trying to say.

07/19/07 @ 13:26
Comment from: karl dubost, w3c [Visitor] · http://www.w3.org/QA/

Another way to explain it is given in the CHIPs W3C Note.

See http://www.w3.org/TR/chips/#uri

Most of the Web sites are now dynamics and not static. A URI is a reference, it can be a call in cgi, a database, a file, etc. If you look at Content Negotiation, it helps also to understand.

07/31/07 @ 14:51

Leave a comment


Your email address will not be revealed on this site.

Your URL will be displayed.

Please enter the phrase "I am a real human." in the textbox above.
(Line breaks become <br />)
(Name, email & website)
(Allow users to contact you through a message form (your email will not be revealed.)
September 2017
Sun Mon Tue Wed Thu Fri Sat
 << <   > >>
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30

Search

The requested Blog doesn't exist any more!

XML Feeds

powered by b2evolution free blog software