This post originated from an RSS feed registered with Python Buzz
by Phillip Pearson.
Original Post: API survey: does anyone handle multiple RPC systems properly?
Feed Title: Second p0st
Feed URL: http://www.myelin.co.nz/post/rss.xml
Feed Description: Tech notes and web hackery from the guy that brought you bzero, Python Community Server, the Blogging Ecosystem and the Internet Topic Exchange
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.
Previous Topic
