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

[msilverstar]

ONG access to the inbox, I have 5K messages from importing a big LJ and cannot stand deleting them 10 at a time. I would like to select based on

Your entries have failed to import and will not be retried.
XMLRPC failure: Client error: Invalid text encoding: Cannot display this post. Please see http://www.livejournal.com/support/encodings.bml for more information.

and delete them all!!!

I asked Denise when I reported it but she was more interested in fixing the inbox spam than deleting from my personal inbox.

[casimirian]

This documentation is gorgeous and so useful. Thanks. :)

[momijizukamori]

No problem! Once I get the actual code done I'm going to clean up the docs generator some and maybe see about sorting the routes a bit better so it's more navigable.

[gatheringrivers]

Yay, thank you!! :)

Push notification helpers: Prowl (for iOS), and Notify My Android

[mek]

There are some stand-alone mobile apps which make it very easy to send arbitrary push notifications to a mobile device.

iOS: Prowl https://www.prowlapp.com/
Android: Notify My Android http://www.notifymyandroid.com/

Your code can make a single HTTP request from your server, and these applications (and their back-end-services) do all the rest. Using these services/apps, sending arbitrary push notifications becomes nearly a one-liner.

I don't have personal experience with Notify My Android, but I've used and integrated Prowl (iOS) into a few projects quickly and easily.

Each user who wants notification would have to install the (appropriate) app, and provide DW with their unique notification key, which they obtain from the app. Then DW servers make one quick, light HTTP request with the user's key in it, and poof, notification pops up.

Prowl lets you not only include the notification message, but also an optional URL that the user can click on to go right to the relevant page (e.g., to see a newly posted comment).

I'd be very happy to help out, including doing some prototyping.

UPDATE: turns out you can also just send an email to {apikey}@api.prowlapp.com, and the mobile device will get a push notification.

/api/v1/journals/{username}/entries/{id}

[darael]

I see that you've decided to use POST for entry-editing (presumably by way of wholesale replacement). Have you considered allowing PATCH, which is intended for the purpose? I realise you'd have to either figure out how to apply application/json-patch+json to some kind of JSON representation of an entry, or break consistency and use text/x-patch as input, but it might be worth it for small edits on large entries.

[darael]

Related: some analogue to the &thread= functionality on the main site, getting a comment and all its children. redir_type=threadroot would be a bonus.

Re: /api/v1/journals/{username}/entries/{id}

[momijizukamori]

Yeah, the idea with POST was basically to mirror the way on-site edit functionality works (with the bonus of being able to co-opt a bunch of the existing pathways for doing that). I hadn't considered PATCH, though since writing this initial spec we've swapped to OpenAPI3.0 which is a lot more flexible about content-type.