The simplicity of this is striking. Here’s a great example of how a business application like an online spreadsheet can become oh-so-more-useful when it can integrate external data in interesting ways via RESTful APIs.
aehso google, rest, xml
I completely agree with Brad and Fred – Alex Iskold’s The Structured Web and Facebook: What If More Is Less? contain some great concise analysis of the how the web and the networks within it are evolving.
Well worth a read if you’re looking for some food for thought and can spare 10 minutes….
aehso atom, blogging, rss, social, web services, web2.0, xml
Tim Bray bites back at Dare Obasanjo’s recent critique of APP.
There are places (network TV, Middle Eastern politics) where cluelessness regularly triumphs. Internet protocols aren’t one of them. Sorry, Dare.
Ouch! I definitely have to re-read the APP specification and play a bit more with Abdera or some-such before deciding (Bill de hÓra’s related post also appears to be worth understanding)…
aehso atom, xml
This should be an easy one for Google to fix but it’s still borken. Since the weekend, Google Mobile Reader on Opera/N800 is failing to render the home page with the following error:
XML parsing failed: xml processing instruction not at start of
external entity (Line: 5, Character: 0)
The offending page content reads as follows:
<!--
Content-type: Preventing XSRF in IE.
-->
<?xml version="1.0" ?>
<!DOCTYPE html PUBLIC "-//WAPFORUM//DTD XHTML Mobile 1.0//EN"
"http://www.wapforum.org/DTD/xhtml-mobile10.dtd"><html
xmlns="http://www.w3.org/1999/xhtml"><head><itle>Google
Reader</title>
<meta http-equiv="content-Type" content="application/xhtml+xml;
charset=UTF-8" />
<style type="text/css">
...
Err, why is there a comment before the XML declaration? If this is supposed to be valid XML it shouldn’t be there. I’m surprised the various other mobile platforms are forgiving enough to ignore this (or is it borken on them too and nobody has noticed?). Please Google, fix your XML.
(discussion ongoing here)
aehso atom, google, rss, xml
A recent discussion on rest-discuss related to describing RESTful resources has lead to interesting discussion by Aristotle Pagaltzis, Stefan Tikov and Don Box on the topic. They highlight a couple of issues that have been bugging me (at Oisin’s expense I think!):
- How should RESTful clients bootstrap into a RESTful system, or rather, how does the client determine the correct payload to send to the first RESTful resource it interacts with? Currently it appears that there must be some out-of-band definition of the first RESTful resource request that the client has ‘baked-in’ in order to initiate a conversation with a set of RESTful resources. HTTP Web browsers solve this problem through (bookmarked) URLs. Should all RESTful resource clients do the same?
- How should RESTful clients interpret arbritrary XML response payload? The response XML is presumably defined by a schema (somewhere) but I’m wondering how is a RESTful client expected to interpret the semantics of the XML unless it has prior knowledge of the schema. Is this prior knowledge just assumed? Again, HTML browsers succeed in this regard because they are build on the semantics of the HTML language schema.
I’d be very interested if anyone has insights into the above two questions. If knowledge of the schema(s) is assumed (Aristotle’s post implies this) then perhaps all folks are looking for is guidance on how to determine which XML element definitions are expected/returned by RESTful resource request/reponses.
Perhaps that’s where the value in WADL lies. Unfortunately WADL seems to promote static resource set definitions, as WSDL does for WS-* service endpoints. Perhaps if the WADL resource set definitions could also reference other WADL resource set definitions then we might have something a bit more dynamic?
aehso rest, soa, web services, web2.0, xml
Recent Comments