Comments | lj_dev: undocumented XML-RPC methods

jfelectron in lj_dev

undocumented XML-RPC methods

Dec 02, 2009 12:03

Some googling and testing revealed the following undocumented XML-RPC methods, which expose a number of nice functions from the client side.

All are in the LJ.XMLRPC namespace of course:

getfriendspage
sendmessage
setmessageread
getinbox
addcomments

These were gleaned from: code.livejournal.org/trac/livejournal/browser/trunk/cgi-bin/ljprotocol. ( Read more... )

client, server: documentation, *unanswered, *report (lj), client: xmlrpc, server

Comments 18

pauamma December 5 2009, 23:27:12 UTC

This codebase is over a year old, it looks like they aren't using that repository.
Not sure what you mean there - that repository is the current, official one, and last commit to ljprotocol.pl was a few days ago.LJ support is useless.
Not useless, just geared toward end-user questions, not dev-type questions.Is there another way to contact LJ devs?
This comm. There's at least one LJ dev reading it, and some of the regulars (including me) can file bug reports.

(The comment has been removed)

jfelectron December 6 2009, 12:28:52 UTC

@pauamma: Err...yes. I based this erroneously on there being a lot of old commits.

@duskwuff: Yes getfriendspage is incredibly basic, but its better that screen scraping!
The method could easily be expanded to include other useful stuff.

Yes, the random base64 encoding is annoying. Its not clear to me exactly what is being encoded. Can you get anything usable out of decoding? Is it an image file?

(The comment has been removed)

jfelectron December 6 2009, 20:57:11 UTC

Ooops...yeah. The xmlrpc client I use for testing was barfing on the base64 and returning some strange array of numbers, which I failed to see was not base64 :).

You're right, its just the raw HTML of the post body that gets encoded. Its a total mystery what triggers this.
I trolled through the code to see if I could see where the base64 is happening, but I couldn't find anything obvious.

Thread 9

gregstoll December 7 2009, 23:54:19 UTC

Wow, this is awesome! I'm working on a LiveJournal client for WebOS devices (Palm Pre, Pixi) and doing some screen scraping, but this is like 50 times better. Thanks a bunch!

jfelectron December 8 2009, 01:42:58 UTC

Yeah...actually I am too. Developing a WebOS client that is. There is still some screen scraping required. For instance, while getfriendspage gets you the text of the posts and tells you the number of comments. You still have to scrap the mobile page of the post to get the text of the comments. Also, addcomments is restricted to paid users so its not a general method that can easily be used in an app. Add comments includes both authentation parameters and a 'poster' parameter. What I need to try is whether one can use the credentials of a paid account to call addcomments while posting a comment with 'poster'. So if the dev has a paid account maybe it will be a general mechanism. I doubt this will work because the system presumably uses the supplied credentials to determine which journals you are allowed to post to.

gregstoll December 8 2009, 01:47:52 UTC

Yeah, I realized this after my initial exuberance. At least this beats parsing the friends page...

I found a way to reply to posts/comments without using the addcomments method by using an ECP hash.

ghd_mk4_gold June 27 2010, 07:08:31 UTC

Is it real or not?

gregstoll December 8 2009, 02:39:16 UTC

Would it be possible to fix the getfriendspage flat entry point to return the reply_count? The XML-RPC version returns it, but it's not in the list of attributes to look at on line 3450 of that file.

I'd be happy to submit a patch if that would make it happen...

Thanks!

azurelunatic December 8 2009, 22:25:56 UTC

I would be happy to host this as a feature request in suggestions; I can't imagine that it would cause any troubles. Over the years the field to put the suggested implementation has been removed from the suggestions form, but you can stick it in the full description.

http://www.livejournal.com/contact/suggestion.bml

I don't know how fast it could be implemented even with a patch, because a) there's a bit of suggestions backlog due to me being technically on vacation, b) developer priority for reviewing and committing patches from external developers are low. I just checked in with andy in IRC, and he confirmed that through suggestions would be best as that's the formal route.

gregstoll December 9 2009, 16:04:32 UTC

Cool, I'll go ahead and do that. I actually rewrote that part of my app to use the XML-RPC interface just because I was dying for the reply_count, but it would be nice to have for future developers.

Thanks!

azurelunatic July 25 2010, 15:10:20 UTC

(and for crosslinking purposes)
The suggestion: http://community.livejournal.com/suggestions/981061.html

jfelectron December 8 2009, 03:27:54 UTC

Well its an undocumented method. It is strange that the flat protocol returns different things, but they are implemented separately rather than one being a wrapper for the other. Are you sure that its not returning it?

gregstoll December 8 2009, 03:29:58 UTC

Ah, that is true.

Yeah, I'm parsing the rest of the responses, but reply_count isn't being returned...