On May 25, 2011, at 2:47 AM, Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯 wrote:
REST The rest of the message doesn't read like that. I'll pretend you wrote "HTTP API" instead.
Care to explain? Most likely you are correct, but I would like to understand why I wrote REST and thought I was talking REST but actually ended up talking HTTP API? From what I understand about REST -- every "item" that is to be retrieved via a URI is a resource (the R in REST). Every URI results in a unique resource, and every resource has one and only one URI. Hence, the URI can be thought of as a name of the resource, the really, truly unique resource identifier. The only interface to the world is the URI (the "name" of the resource), and a handful of verbs, namely GET, PUT, POST and DELETE, in the world of HTTP. Am I talking nonsense above? And, is there a disconnect between what I am thinking I am doing and what I am actually doing?
Any other thoughts on such an application design? In addition to what Brian said, Google built a convention around hash fragments to make AJAXy resources crawlable. It's a hack to accomodate people who didn't know better about the drawbacks and are now stuck with their horrible design. I call it a hack because AJAX by itself, unlike other Web tech we have seen so far, does not degrade gracefully; see and puke for yourself: <http://code.google.com/web/ajaxcrawling/>
I like this bit <a href="ajax.htm?foo=32" onClick="navigate('ajax.html#foo=32'); return false">foo 32</a> I didn't know I could do the above, and that seems like a good design feature. That said, I have the following clients -- (1) the web users whose only interface to my data and application is the web interface; (2) a program, such as a scientific application, that wants access to my data via a command line, so it can do it own work, say, modeling. Or, even a user who just wants to download the data for further use elsewhere; and now (something I really hand't thought of until your email) (3) the darned web crawler. Actually, I had sort-of thought of the web-crawler because I asked about permalinks. Of course, there is the question -- do/should my data be exposed to the web crawler? It may make sense for certain kinds of data, but what about highly discrete, small data? Say, weather readings -- I have a historical climate dataset for the US that, if I were to count each reading separately (in other words, each bit of data that would be retrieval via a unique name, or a URI), it would be upward of 120 billion (yes, no typos there... 120 Billion). Is there any point in pretending it is all a static web, and letting Google have at it?
Since you are still in the design phase, design your interaction properly with *progressive enhancement*. Write semantic markup and forms that work in a text browser. Then apply styles. Then apply JS that modifies the behaviour of an existing document to load partial content with AJAX. Employ pushState so that the URL changes the same way like it would for a user agent without JS. I can recommend jQuery BBQ to handle these bits.
I am gonna learn about pushState today, and jquery-pjax. What is jQuery BBQ?
_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users