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

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