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

Access to the accesslist membership lists?

[siderea]

Okay, I'm back.

You have:

/api/v1/journals/{username}/accesslists - GET, list of access lists for journal

How about allowing manipulation of accesslists by API? In parallel with your other URLs, we could have:

/api/v1/journals/{username}/accesslist/{accesslistid} - GET, list of members of access list; POST, save list of members of access list.

But honestly, I would feel better, as a developer, being able to add or subtract individual users from an accesslist, rather than having to overwrite the whole thing every time I made an edit. The latter seems like a recipe for really awful bugs.

Use cases: GET: being able to retreive a list of members means I can back up my access lists, something that is important to me, and actually super hard. I've also kicked around an idea of combining such a feature with OpenID, such that I could run a website where if users authenticate there with their DW OpenID, they can have access to things based on my access lists – basically API access to my accesslist memberships lets me use DW's ACLs elsewhere. So I could, for instance, set up sound or PDF or video sharing just for people on my access lists. POST: remote/client management of membership.