darael: Black lines on a white background.  A circle, with twenty-one straight lines connecting seven equally spaced points. (Default)
Darael ([personal profile] darael) wrote in [site community profile] dw_dev2014-04-20 01:53 am
Entry tags:

On clients and APIs

Dreamwidth's APIs are poorly documented (people basically have to work off docs for old versions of LJ's APIs). They're also missing key features, like comment handling for more than backups.

I've been told there have been "some internal conversations about deprecating the XML-RPC API -- keeping it for backwards compatability, but moving to a much more modern second-gen API", but that nobody has had both the time and the inclination to work on designing such a thing.

Well, this is me, volunteering. To that end, I'm looking for input on what exactly such a new API needs to provide, and whether there's a preferred underlying technology to build on (exempli gratia, stick with XML-RPC? Change to SOAP? Use JSON? RESTful or not? et cetera). What I'm getting at here is that I'm entirely happy to take point, as it were, and to make decisions (especially where there's little or no consensus and someone has to make the call), draw up specs, write docs, and so forth, but the result is highly unlikely to be a really useful API unless I get input from more sources than my own experience and looks at the code.

At this stage, therefore, I want everything you, the reader, have to say on the subject. Use cases especially.

Go.

[personal profile] alexbayleaf 2014-04-21 10:00 am (UTC)(link)
As a potential developer/user of this API, I would like to say: OAuth, REST, JSON.

Given those things, I would almost certainly develop apps/tools/something using them, and perhaps contribute to a Ruby gem to wrap it all nicely.
fu: Close-up of Fu, bringing a scoop of water to her mouth (Default)

[personal profile] fu 2014-04-22 07:45 am (UTC)(link)
As a potential developer/user of this API, I would like to say: OAuth, REST, JSON.

Yes, yes, and yes.