this post was submitted on 30 Jun 2023
32 points (97.1% liked)

Lemmy

12575 readers
1 users here now

Everything about Lemmy; bugs, gripes, praises, and advocacy.

For discussion about the lemmy.ml instance, go to !meta@lemmy.ml.

founded 4 years ago
MODERATORS
 

Lemmy's API documentation currently appears to be the JS client implementation found here: https://join-lemmy.org/api/

This is very misleading, as these docs document the behavior of the JS client and do not provide a language neutral way to figure out what's going on.

Compare Lemmy's docs with something like the ActivityPub docs https://www.w3.org/TR/activitypub/

Going off ActivityPub, I could actually start to see how it all works and looks together. With Lemmy, I can reason about how the JS client works and do my best, but working with Lemmy you sometimes have to consume the Rust source as well.

So, this raises the barrier of entry for someone wanting to do Lemmy integrations to someone that needs to consume the above docs, plus be comfortable reading JS and Rust.

I saw some older posts from the lemmy devs saying: "Well, writing docs is hard, so it's easier if we generate the docs from our JS client."

They aren't wrong, writing documentation IS hard. If Lemmy is serious about attracting a larger ecosystem, I consider better API documentation to be on the hot path. I'm concerned that the devs are happy with the autogenerated docs above and won't put any effort into improving them. Even worse, the people generating these docs are already familiar with Lemmy, so they probably think the current docs are adequate.

I don't know a quick solution -- raise money to pay someone to write docs? No clue. But, if you want to attract developers to this ecosystem, the current API documentation is insufficient.

you are viewing a single comment's thread
view the rest of the comments
[–] qprimed@lemmy.ml 14 points 1 year ago* (last edited 1 year ago) (2 children)

at this point the codebase is in daily flux, it really comes down to RTFS. the transition from websockets to http seems to be mostly in-place, so there may be some opportunity to begin normalizing the docs.

totally agreed on the need for more complete and accurate documentation, but without an auto-documenting sourcecode framework, I would expect API documentation to lag. in the meantime we just live life on the edge - it will improve over time.

edit: word

[–] picoblaanket@lemmy.ml 3 points 1 year ago

Yes exactly - living on the edge!

One way to learn the new API is - explore the code of (similar) extensions and browser scripts, to see how they build and send their calls.

[–] yarr@lemmy.fmhy.ml 2 points 1 year ago

I was curious to see if the reply was going to be:

  • We are happy with the state of docs (WONTFIX)

OR

  • The current situation is temporary and we will provide better docs at some point in the future