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

[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.