Comments on: Designing a JavaScript client for a REST API

By: shadedecho

shadedecho — Tue, 17 Feb 2009 21:27:14 +0000

@jared-understood, the flash “barrier” is not something so trivial as to not think about or take for granted. Not to hijack this thread too much, but to address your flash concern, I did have a couple of thoughts (as I’m very opinionated and passionate about this particular topic).
.
With *so* much flash out there, and with Adobe reporting numbers in excess of 99% global penetration, and with those same numbers even showing *huge* (>50% over 3 months) rates of adoption of their latest 10.x plugin version, I think we’re getting to the point where flash is arguably a ubiquitous technology. It is certainly more ubiquitous than Java, Silverlight, or even any one single browser.
.
And, in the same way that you need to provide a “graceful degradation” (or, depending on your perspective, “graceful enhancement”) for those with or without javascript support (etc), I think the same can be true of flXHR and flash based solutions.
.
For instance, you can use the underlying javascript toolset (CheckPlayer, built on top of SWFObject) to easily upfront detect if flash is enabled for the end-user, and of the right version, and then fork your logic at that point to handle it however you see fit.
.
One way (what I think is the best user experience) is to use Adobe’s express-install (which flXHR fully exposes) to automatically and in-line, in the same browser page/instance, provide users a way to update flash as necessary. With well over 99% of people on the internet having *some* flash installed, that’s an incredibly high number of people that will be able to simply upgrade their plugin and use your site as you intended with minimal user-experience impact.
.
On the other hand, you could have that same flash (version) detection logic simply decide that if they don’t have the flash installed, then dynamically you load a simple “shim” script like the one for doing the dynamic-script-tags, or another one which does dynamic iframes, to take the place of flXHR.
.
If you choose/design that “shim” in the right way (that is, with a compatible API to normal native XHR, like flXHR did), or at least some wrapper thereof, it’ll br a graceful fallback for non-flash users and the rest of your code logic is happily unaware.
.
The reason I advocate choosing flash (flXHR) as the primary (rather than fallback) method is that there are important benefits to be gained in terms of security (the full server policy model leveraging) and efficiency (one small flash instance as opposed to several memory-hogging invisible iframe instances). Also, the communication part of flXHR uses no timers (or ugly JSONP callbacks), so in general it should be quicker and more direct to get data to and from the server. In performance tests, it performed admirably and competively with several other various popular cross-domain solutions.
.
My point is, a few years ago, the argument against flash as mission critical app technology was compelling. But nowadays, I think it’s much less so, and really it’s only a few stalwart holdouts who refuse to embrace the parts of flash that can genuinely be helpful in UI technology and better UX.

By: shadedecho

shadedecho — Tue, 17 Feb 2009 15:51:03 +0000

Another option for the cross-domain XHR, if you don’t want to hack around with a bunch of timers and iframe creation (very memory intensive and time consuming for clients) is to use flXHR [ http://flxhr.flensed.com/ ] which is a javascript+flash re-implementation of the identical native XHR object’s API, but since it uses an invisible flash component, it can make cross-domain calls if the server opt-in policy allows it. Since the API is identical, flXHR drops in as a simple replacement without *any* futher coding changes, even with frameworks and existing code that know how to speak to an XHR object.

By: loveencounterflow

loveencounterflow — Tue, 17 Feb 2009 15:28:42 +0000

more to the point: “”"For HTTP methods other than GET (e.g. HEAD, POST, PUT, DELETE), script transport would require disguising the request as a GET, which has different semantics. Then there’s also the fact that a large request might not fit into a single URL. There must be a better alternative.”"”—YES, there is a better alternative. do not disguise a DELETE request as a GET request. just cut it out. you want to DELETE http://example.com/product/42 ? fine. goto http://example.com/delete/product/42 and you’ll be fine.
.
while we’re at it: RESTfolks always try to sell DELETE and PUT—what if i want to BUY product/42? will i have to issue an HTTP BUY request to http://example.com/product/42 ? what if it’s time to checkout? do i have to issue an HTTP CHECKOUT to http://example.com/shop ? what if i want to pay? issue HTTP PAY http://example.com/cashregister/$7.00 ??
.
this is hilarious.

By: loveencounterflow

loveencounterflow — Tue, 17 Feb 2009 15:21:12 +0000

this is an excerpt on the topic of “CRUD”-style RESTful interfaces; originally posted to http://jjinux.blogspot.com/2009/02/rest-restful-shopping-carts.html
where you can also read a nice discussion on the subject.
.
i’ve said it before, and i’ll say it again, 10³ times if necessary: if RESTful means you go from GET and POST to GET, POST, PUT, DELETE—then it’s a bad idea.
.
RESTful thinking is a great tool to clear up in your mind essential principles of the way the web works. GET, POST, PUT, DELETE are not so hot. GET and POST are great, they are what is actually implemented in browsers, and they’re sufficient. to put CRUD (Create, read, update and delete) into the HTTP method is bad.
.
any semantics that go beyond the ‘underlying request modalities’ of HTTP communication do NOT belong into the HTTP method, they belong into the URL. One very obvious piece of evidence to corroborate this is the fact that in a RESTful app, you cannot specify both your object and your intent in one URL.
.
that there are even more HTTP ‘verbs’—HEAD, TRACE, OPTIONS, CONNECT—that are not really talked about within the RESThype makes me suspicious. i want to argue that just as there are HTTP methods that are seldomly used (at least not by clients, only under the hood), so there are HTTP methods that got designed once, but are as superfluous as e.g. the POP and the FTP protocols (they got invented when HTTP was less prevailant than today—one protocol for a single purpose. they can’t do anything that HTTP can’t do).

DELETE and PUT are just as obsolete as the [font/] tag—they looked like a good idea at the time, and when they got replaced by something (much) better, no-one looked back.

By: halans

halans — Mon, 16 Feb 2009 21:51:28 +0000

Great article!
Same could apply to developing bookmarklets, like (warning, blatant self promotion coming up) my own http://www.mapanui.com , which could use some improvements, like what you described here.

By: EdSpencer

EdSpencer — Mon, 16 Feb 2009 20:32:36 +0000

Excellent article.

Talking to other domains is a pain point I’ve been fortunate enough to avoid so far but I’ll refer back to this when my luck runs out. Thanks!

By: vikingstad

vikingstad — Mon, 16 Feb 2009 16:24:40 +0000

JSONP doesn’t necessarily require a proxy, that is completely up to whoever implements it.

By: Michael Mahemoff

Michael Mahemoff — Mon, 16 Feb 2009 14:40:03 +0000

See also http://softwareas.com/cross-domain-communication-with-iframes – there are some basic demos of both the approaches described here (“URL polling” and “Marathon”).