Thursday, February 15, 2007

Two articles on "REST", over 10 years apart. What's changed?. What's the difference between these two articles, which are over 10 years apart: "Web 2.0, REST and BEA Workshop" [2007] and On-Line Componentware [1996]. Not an awful lot. I still have the Byte issue in which Jon Udell talked about calling AltaVista using a Perl Script. It's an issue with "Java Chips" on the cover, and it's sitting in a box in an attic in north Dublin. Jon Udell's column talked about calling a URL programmatically by passing parameters in a Query-String, and then parsing the HTML results into Perl variables. In the BEA example, the data comes back as XML and is parsed using Java. But the principle is the same.  For me, that Byte article was important because it bridged the world of programming / distributed computing (which I'd learnt about in college) and the world of the Web (which was taking off then, but was mostly focussed around publishing and graphic design). I used the idea in Jon Udell's article to design systems for the Irish Government  (in 1998) and for Intel (in 1999), calling a same URL via a scriptable Java applet in a browser and via a C++ MFC application. But back then we didn't call it "REST" or and we didn't call that Web component which we called from multiple heterogenous clients a "Web Service". It's interesting that the whole "Web Services = SOAP" thing has gone so far that BEA has to remind people that you can use their products to go a simple HTTP GET, something you could easily do 10 years ago! Mark Baker had it right in 2003 when he said: "There are a whole lot of REST tool kits available, it's just that people don't know what they are".   2:01:51 PM    comment []

Eval is still evil, even for JSON I gave a talk last week at the RSA Conference on "Security for AJAX and Web 2.0". The slides are available here. One of the things I mentioned was that the use of eval() to parse JSON is a security hazard ("eval is evil"). An attendee in the audience rightly pointed out that this eval-ing of JSON mostly happens on the browser client, with the data coming from the server, so it's not quite "never trust your input". But in the case of mash-up situations where a single domain is acting as a proxy for multiple data sources (common situation due to the connect-to-origin-domain-only security limitation of AJAX) there is a scenario of "never trust your output" (when you are proxying it from somewhere else). ParseJSON() is the better way to go. What I'm worried about is that if a developer is using JSON instead of XML since XML is a lot of overhead and hassle, it follows that they might also think ParseJSON is also a lot of overhead and hassle. Elliotte Rusty Harold also predicts this week "at least one major security breach as a direct result of passing JSON data to the eval() function.". 1:05:13 PM    comment []