Brain on Fire Tim McCormack, distilled.

When a GET hits your server, your RESTful webapp should not alter the database. Why not enforce this at the permissions level?

Due to a lawsuit by Eolas against Microsoft, Internet Explorer (both 6 and 7) is not allowed to auto-load movies, flash, and other plugins. The effect is that users must click an empty area with a gray outline to load the content or start interacting with it. The standard approach to route around this usability fiasco is to dynamically load the <object> and <embed> tags with javascript. Here I present an easier, more readable, and unobtrusive technique for embedding content in IE6 and IE7.

I thought I was being so clever when I put a content-negotiated API into TradeUps.net, my web development playground. To put it simply, a page can return the same information in different formats, depending upon the HTTP Accept: header. For example, this profile page (view only in Firefox for now) responds to a standard browser request with an HTML document, but returns JSON when it sees Accept: application/json as a header. In this case, a script on the page calls the same URL (/user/admin) again to get the map data in javascript-friendly format. That's where the weirdness starts.

I'm having difficulty deciding what is the best approach to returning from a POST request to one's web app. I'd like to deliver messages to the user about the results of the request, I want to avoid some nasty POST-related browser behavior, and proper bookmarking would be sweet, too. Unfortunately, it seems I can only have 2 out of the 3 with any given strategy.

My local paper, the Daily Progress, ran a story today about a proposal to install 30 security cameras on the Downtown Mall. I think there's a wrong way to do this, and a right way. I'll explain why the wrong way is wrong, and suggest a scheme that could lead to a right (or better) way.