David Watson has a service that can be used to fetch referral information into Radio pages. " I don't believe it'll work outside my firewall without redirects," writes David. That seems to be true. From outside his firewall, the URL http://www.watsondesign.comsoap/urn:rcsproxy/getReferers?site=0100887&group=radio1 works in my browser, but not by way of a Frontier tcp.httpClient call. When I use the redirect reported by my browser, though -- i.e. scratchpad.s = tcp.httpClient (server: "24.154.119.166:8080", path: "/soap/urn:rcsproxy/getReferers?site=0100887&group=radio1") -- it does work.
As David points out, his use of The Mind Electric's GLUE, a Java-based SOAP toolkit, means that this SOAP-style web service is also callable using HTTP GET, a really useful paradigm which seems to blunt the argument that SOAP necessarily disrupts the fabric of the web.
Since Radio sites are dynamically updated but statically served, the behavior seen at disenchanted and elsewhere -- that is, per-item referrals shown after items -- ultimately calls for a solution that fetches referral data from the community server, correlates it by referred-to page over time, and then updates the site accordingly.
What kind of web service this could be is an interesting question. Undoubtedly many Radio users would prefer not to install software to achieve backlink display. A lot of the steps in the process could well be centralized. As the Radio referral data is public, some central service could amalgamate it, so that the task for the Radio client would reduce to including per-item fragments. The Radio pages would still need to be regenerated by the client, though, and this starts to get into a level of overhead that pushes you into the realm of a dynamically served site.
A per-item JavaScript snippet would be an attractive alternative. Not completely universal, but a reasonable solution for most browsers, and far simpler on the whole.
This kind of loosely-coupled solution might or might not involve SOAP. The truth is that a third-party backlink-display system for Radio users might use nothing more than HTTP GET, both to fetch the data in the first place, and then to answer JavaScript calls. But since HTTP GET and SOAP are in fact quite compatible, I'd argue that building a SOAP API is not a waste of time. It would create a richer set of integration possibilities, without precluding the simple and basic approach.
Former URL: http://weblog.infoworld.com/udell/2002/05/06.html#a216