Cocoa (![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
momijizukamori) wrote in ![[site community profile]](https://www.dreamwidth.org/img/comm_staff.png)
dw_dev2019-05-11 10:55 am
momijizukamori) wrote in dw_dev2019-05-11 10:55 am
Entry tags:
API things
I kept meaning to write this up but kaberett's volunteer weekend was a good extra nudge, heh.
what is live
- To generate API keys (and delete them), go here - this can be found via Manage Accounts -> Mobile -> Advanced Options (which is at the bottom of the mobile tab)
- The JSON-formatted spec is here and doesn't require an API key to access - we don't have a more human-friendly version yet, though any client that can parse OpenAPI v3.0 specs can take that - Postman is the one I've tried.
- There are not many routes yet - we wanted to get the backend solid before adding stuff that had potential privacy/security risks if something in the backend was wrong
- To use the API key, you need to add an Authorization header to your HTTP request with the value 'Bearer [api key]'.
what is in progress
- I have a pile of routes mostly-written, in this branch. They probably need some light editing, as we moved from OpenAPI v2.0 to v3.0 after I wrote these, and we also hadn't implemented API keys yet. They also need LOTS AND LOTS of testing, oh god please, I'm so bad at QA.
- I wrote a quick'n'dirty primer to adding moar routes here on the wiki. Happy to answer additional questions on it!
what really needs to be done
- TESTING TESTING TESTING
- image-upload-by-API is near the top of the list of 'most wanted things I haven't written yet'
- I want to add a nice UI for the spec a la redoc but I'm not totally sold on that as a look and could use design input and inspiration
- We really need some intro/'API for beginners' text to go on said doc page, I am probably not the right person to write this because I Know Too Much
- It would be great to have a priv system for API keys (so that you could make a key that can read and not post, or vice versa). There are stubs in the API key files for this, but it needs UI and DB stuff as well as... filling out the stubs.
- 404s under /api should really return a JSON 404 message and not... the entire HTML output of the 404 page.
kaberett's volunteer weekend was a good extra nudge, heh.what is live
- To generate API keys (and delete them), go here - this can be found via Manage Accounts -> Mobile -> Advanced Options (which is at the bottom of the mobile tab)
- The JSON-formatted spec is here and doesn't require an API key to access - we don't have a more human-friendly version yet, though any client that can parse OpenAPI v3.0 specs can take that - Postman is the one I've tried.
- There are not many routes yet - we wanted to get the backend solid before adding stuff that had potential privacy/security risks if something in the backend was wrong
- To use the API key, you need to add an Authorization header to your HTTP request with the value 'Bearer [api key]'.
what is in progress
- I have a pile of routes mostly-written, in this branch. They probably need some light editing, as we moved from OpenAPI v2.0 to v3.0 after I wrote these, and we also hadn't implemented API keys yet. They also need LOTS AND LOTS of testing, oh god please, I'm so bad at QA.
- I wrote a quick'n'dirty primer to adding moar routes here on the wiki. Happy to answer additional questions on it!
what really needs to be done
- TESTING TESTING TESTING
- image-upload-by-API is near the top of the list of 'most wanted things I haven't written yet'
- I want to add a nice UI for the spec a la redoc but I'm not totally sold on that as a look and could use design input and inspiration
- We really need some intro/'API for beginners' text to go on said doc page, I am probably not the right person to write this because I Know Too Much
- It would be great to have a priv system for API keys (so that you could make a key that can read and not post, or vice versa). There are stubs in the API key files for this, but it needs UI and DB stuff as well as... filling out the stubs.
- 404s under /api should really return a JSON 404 message and not... the entire HTML output of the 404 page.
no subject
Ah, okay! The new entries API doesn't have a markdown flag yet - it expects entries to come in as HTML - but adding one is definitely in scope.
Honestly at this point the big things are 1) properly implementing ratelimiting, 2) working out what the comments API should look like (which is a design question more than a coding question), and 3) a LOT of testing. (3) is the bit that I could use the most help with - I'm not great at QA, and there's a lot of variables to test.
no subject
I am not QA expert either, but I like writing unit tests (if they are applicable in this case), I can play with API and see what is working and what is not (I am sometimes good in finding patterns that does not work), and I also can starting to implement script I need, it would be both, API testing and I will have workable script, as soon as API is commited in prod.
So I guess, first thing I need to do is to request own hack.dreamwidth.net and install api-more branch there...
Update: I managed to create account on http://www.momiji.hack.dreamwidth.net/, so I will not need my own hack for now. I will start writing script that do both REST-API request and XMLRPC one (or pure web-site requests if something does not work in XMLRPC), and make sure that results are same. This script can be later used in some integrity check procedure.
This will not be quick, I will use my hobby-time for it, but sooner or later I will finish it.
no subject
Hah, still ahead of me, I'm only very grudgingly coming around to make unit tests a regular part of my coding via my day-job.
Let me know if you run into any weirdness, either via a comment here or a DW private message - I have email notifications turned on for both, even if I am sometimes slow to get around to writing replies. I'm hoping I'll have some energy to work on DW code as the weather warms up and the days get longer, and having people wanting to use and help with it is definitely a motivator :)