momijizukamori: Grey tabby cat with paws on keyboard and mouse. The text reads 'code cat is on the job', lolcats-style (CODE CAT)
Cocoa ([personal profile] momijizukamori) wrote in [site community profile] dw_dev2017-10-10 10:29 pm
Entry tags:

API wishlist?

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)
gatheringrivers: (Cats - Ack / Surprise)

[personal profile] gatheringrivers 2017-10-13 05:08 am (UTC)(link)
Not sure this was covered, and my geek-speek is kinda impaired lately with crap sleep.

My suggestion:
Force the API to recognize security levels (filters) on posts. As in, if there is no implementation of filter levels, the only posts the script/program can see are public ones.

Reason:
There was some hullabaloo a LONG time ago about one of the various third party LJ apps (I don't remember which one, it was at least a decade ago that I heard about this) being able to *completely* bypass post filters/security levels, allowing anyone using that particular app to see *any* post on a journal, regardless of whether the user was included on a filter for that post or not.
green_knight: (Eeek!)

[personal profile] green_knight 2017-10-13 08:00 am (UTC)(link)
Yikes. (That must have been before my time, so over a decade ago, but that sounds like a spectacular failure.)

gatheringrivers: (Default)

[personal profile] gatheringrivers 2017-10-15 07:38 am (UTC)(link)
It was! Those who knew about it sometimes set up "secret journals" with only trusted people having access/knowing the address.
gatheringrivers: (Default)

[personal profile] gatheringrivers 2017-10-15 07:40 am (UTC)(link)
Please make sure that's enforced on the side of DW servers rather than the client. :)

With everything in the news, I'm sure people will appreciate feeling more like private/filtered entries will actually STAY that way regardless of how people access the journal.
gatheringrivers: (Cats - Happy Cat)

[personal profile] gatheringrivers 2017-10-18 05:03 am (UTC)(link)
Yay, thank you!! :)