API updates - looking for testers

[momijizukamori]

Hello friends! It's been a while since the last API update, but I finally got some bugs fixed, and am now at the point of needing testers to help me find the rest of them so we can get this thing going! If you are interested in helping, you don't need any real coding experience, but you do have to be okay at reading docs.

Instructions:
1) Go to http://www.momiji.hack.dreamwidth.net/create and create an account

2) Go to http://www.momiji.hack.dreamwidth.net/api/

3) Paste the bolded token into the box in the authenication section

4) Click on paths to expand them and use the fields to try the requests out.

5) Report errors or unexpected behavior here!

Note 1: Tropospherical layout CSS is not loading properly for reasons unrelated to the API code that I haven't sorted out yet. Other themes work, and site functionality is fine, just kind of ugly

Note 2: The API demo stuff doesn't match the rest of the styling, and will probably only work on relatively recent browsers (the last year or so). This isn't the final form, I'm just using a third-party package so I can get all the backend stuff working before spending time on making the page pretty and matching to out site styles

Note 3: I'm going to try to get the content-importer going for people who want to import some test data, but the workers are fussy to run in development

Stuff what needs fixing
- /journals/{username}/entries claims to return information about the new entry when you post to it, but currently just returns success or failure
- Editing an entry successfully returns no useful information
- Requesting a non-existent entryid on a journal returns confusing error
- Posting entries currently missing music and location attributes
- Posting entries currently missing mood and preformatted attributes

Comments

[casimirian]

Yay! I will assist.

[jazzyjj]

I'll take a look and see what I can do since I've actually had some quality time to myself during the lock-down, lol. But I don't have much programming experience, and my Mac battery hasn't been too happy with me recently.

[kaisa]

I used Postman and Newman for automated API testing (at work) a couple of years ago, is that something that would be useful or have you/someone else done something like that already?

[momijizukamori]

I've poked some with Postman, and more recently with Insomnia - I am unfortunately extremely bad at writing test cases to get all the little weird edge cases, though.

[lunchbreaks]

Kind of a silly question, but is there a way to actually read my entries? I just wanted to see if passing html to the entries post endpoint would resolve correctly or read literally.

Also - great work!!

[momijizukamori]

You can either open up whatever journal you're posting to in the browser, or use the entries API endpoint to pull the new entry.

[momijizukamori]

\o/

[momijizukamori]

Honestly, I'm hoping this will help make things more accessible to people who aren't super-experienced - this format is a lot easier to understand than the old API format.

(iirc you use a screenreader, yeah? I am not actually sure how well the docs generator will work with that - because this is only temporary thing that's not going to be used on the site as-is, I didn't dig too much into accessibility for it)

[lunchbreaks]

Ah ok, missed the url it gives back entirely. Nice!

For anyone else browsing and wondering: yes, it resolves the html

[momijizukamori]

Whoo! Was reasonably sure it wasn't going to mangle the HTML, but I keep moving things around and forgetting to test between changes, so things go awry.

[mdlbear]

It's really good to see this coming along. I especially like the curl commands, for those of us who like to write client-side utilities in Bash. A few anomalies in posting/editing an entry; all as far as I can tell differences from the behavior of the flat and XML APIs, so they're probably just things you haven't gotten around to.

POST /journals/{username}/entries/
* several input parameters appear to be missing; the ones I noticed were "preformatted" and "location", but I'm pretty sure there are others.
* passing non-existent parameters doesn't have any effect, but doesn't produce an error or warning either. That may be a feature.

I originally had returning the entryID when posting, but I see you already have that under "stuff what needs fixing". Consider returning the date as well as the url and/or entryID; otherwise lag between client and server could result in the client having a wrong idea of the date. That's less important, since a client that cares about it can supply its own date.

/journals/{username}/entries/{entry_id}
* POST returns an HTML error page even if the entry exists.
* GET returns 'successfully' when given a nonexistent entryID

[momijizukamori]

Thank you for the feedback! And hmm, updating entries was definitely at least sort of working at one point - I was just trying body text, but it did update. Will see what I did to break that.

When you say it's returning 'successfully' when given a nonexistent ID, what are you getting? I just tried and I'm getting a 403 forbidden error, which is.... not what should be coming back, but doesn't look like success.

The nice thing about using a standardized API format is that there's a bunch of already-existing tools that can generate code snippets for clients!

[momijizukamori]

Okay just poked at editing entries again, doing just entry text at least works for me in curl, the JS docs, and in the standalone API client I'm using. It doesn't return anything other than a 200, which should probably be changed (trying to figure out what expected return types should be is... difficult. Though mimicking the old API when otherwise uncertain is probably a good idea), but if I load the entry, the text is updated. But it's possible some of the other parameters are messed up :|a

[mdlbear]

I was just using the example forms on the JS page; re-checked and edit worked okay -- not sure what I was doing wrong.

I see what was happening with GET -- I was making changes in the low-order digit of the entryID, but it seems to be ignoring the anum portion. When I gave it something that differed in the high-order byte it returned with success=0, although as you say the response code was still 200. On second thought it's not clear what it _should_ be; the _operation_ failed, but one could argue that the API call succeeded.

Edit: The appropriate status code should probably be 404 -- see https://restfulapi.net/http-status-codes/

[momijizukamori]

It's possible you hit it in the middle of me doing some backend tidying - let me know if it comes back.

Can you give me an example query that's returning the weird results? I thought I found where it was being weird but apparently not.

[nataraj]

Hi!

I am interested in more-api. Does any help is still needed?

I've tried to create an account in http://www.momiji.hack.dreamwidth.net/create, but got an "Oops!" page in response.

And http://www.momiji.hack.dreamwidth.net/api/v1/spec does not show spec from api-more branch.

[momijizukamori]

Can you give both things a try again? I forgot new account creation was messed up because of some work I did when we were implementing bcrypt passwords, which I've cleaned up, and I've switched the code base to the more-api branch (instead of the branch for a small bug fix I was working on, heh).

[nataraj]

Yeah. I've managed to create nataraj2 user. (nataraj user is broken as far as I can guess, but this will do).

[momijizukamori]

Yeah I think all the users that were created while my database was messed up have ended up half-created in the system, with no password set so it's impossible to log in as them. I'll have to sit and clear them out manually, probably.