Phillip Pearson - web + electronics notes

tech notes and web hackery from a new zealander who was vaguely useful on the web back in 2002 (see: python community server, the blogging ecosystem, the new zealand coffee review, the internet topic exchange).


API survey: does anyone handle multiple RPC systems properly?

I only just realised that the XML-RPC interface to Flickr just returns the same XML that you get from the REST interface - just encoded as a string so it'll pass through the system properly. This more or less makes using XML-RPC to access Flickr a waste of time, as you have to parse the XML yourself anyway.

The way the current PeopleAggregator API works, it looks "native" no matter which method you use to access it (so you get a properly serialized data structure if you call by XML-RPC, likewise for JSON, and you get a sensible XML chunk if you use the XML call method). Does anyone else do it this way?

The only disadvantage of this approach is that it doesn't do "hi-REST" (read: DAV / APP-style REST, as opposed to x-www-urlencoded GET/POST browser-compatible REST) - i.e. it uses the GET request method when your call will have no side effects, but everything else goes via POST. To delete something, you POST to a URL like .../api/xml/deleteSomething?thingId=..., and so on. I don't think this is a real disadvantage at this point, though, as that type of access is a pain in the ass for clients to use, and will be until people have figured out how to make it look good programmatically.

... more like this: []