API wishlist?

[momijizukamori]

So my workplace gives us a chance twice a year to work on anything we want for a few days, work-related or otherwise, and I thought I'd use some of my time to actually get the new API into a state where we can make it live. With that in mind! What endpoints would you like to see implemented? We're making this Swagger/OpenAPI-compliant, so everything takes JSON as arguments and return JSON formatted data. Stuff already on the list to do or partially done:

/api/v1/users/{username} - GET, shows info about the user (specific info TBD; subset of profile, probably?)
/api/v1/users/{username}/icons - GET, lists icons
/api/v1/users/{username}/icons/{iconid} - GET, returns icon data
/api/v1/users/{username}/journals - GET, returns list of journals with write access.
-- for now, returns only user's primary journal
/api/v1/journals/{username}/accesslists - GET, list of access lists for journal
/api/v1/journals/{username}/tags - GET, list of tags for journal
/api/v1/journals/{username}/xpostaccounts - GET list of xpost accounts
/api/v1/moods - GET list of moods
/api/v1/commentsettings - GET list of allowed comment settings
/api/v1/journals/{username}/entries - POST new entry, GET list of recent entries
/api/v1/journals/{username}/entries/{id} - POST edit entry, GET specific entry
/api/v1/journals/{username}/files - POST new file
/api/v1/spec - GET, returns a description of the API

(Mark and D, as usual, get the final say - some stuff people want may end up being security/privacy risks in non-obvious ways)

Comments

[siderea]

I want to acknowledge I'm dumping a lot out here, and want to apologize if I'm being overwhelming. I was taking that "wishlist" thing at its word.

As a general principle, I'm personally far more interested in the power of third-party apps (mobile, desktop, or even server) to provide functionality to DW that it doesn't have, rather than to provide alternative platforms for access that do what the website (or a subset of the website) already does. I think there's a tendency for APIs for web-based services to be designed to focus on the core functionality of the web user interface; but by opening up the non-core functionality, an API allows third parties to solve problems for the service and provide novel features.

Backup utilities is a classic example, and what with the Great Russian Migration from LJ earlier this year, I think it's on a lot of people's minds. There was no reasonable way to back up one's images from LJ, because the API didn't cover it.

Similarly, providing API access to images allows hypothetical client developers to do things like make phone clients that interoperate with cameras, to make it super easy to post photos to DW. That would probably be a popular feature – it could even make DW more competitive as a platform – but not so certain a thing that DW would want to invest in developing such a client. An API allows third parties to take a stab at it, and DW to benefit by it if they do.

[momijizukamori]

Heh, the reason I started working on the API was to be able to provide utilities for RPers (like generating a list of all your comment threads in a comm, or counting how many comments or entries you made in a month), so I definitely hear you on opening up stuff for other devs to implement non-core functionality like that.

And no worries about the amount of stuff! It may not all get done this push, but it's good info to have going forward.

[siderea]

♥!

So, I'll just add this, while asking for the moon:

/api/v1/journals/{username}/grants - GET returns the list of usernames that username (actually {journalname}) grants access to – and if {username} has that public on their profile, you don't have to be authenticated to the API to get it.

Because I think – not sure, but I've thought cursorily through this – that's the last technical obstacle between here and DW Phone Posts being a viable, commerical third-party service. Not that's I'm promising to start a DW collateral business in my non-existent spare time, but. Just sayin'.

(If there is an unemployed dev ops/sys admin/developer who always wanted her own business, and thinks this might be it, she should shoot me a DM.)

[siderea]

Oh, and! Speaking of asking for the moon:

It would be awesome – and way beyond the functionality of a mere API as presently being conceived – if DW had a settings page that allowed users to create API access keys that granted permissions to an arbitrary subset of DW functionality, so then they could hand the API access key over to a third party, to let that third party act as an agent, with less-than-full control of one's journal.

• A backup service could be allowed to read one's locked posts, but not one's grantors' locked posts, and have no write access at all.

• An automated posting service, e.g. IFTTT, could be allowed to post, but not read or comment at all.

• A design service could be allowed to change one's journal's style, without having any access to locked content, and no other write or read permissions.