• refalo@programming.dev
    link
    fedilink
    arrow-up
    7
    arrow-down
    2
    ·
    edit-2
    4 months ago

    This is still written from a javascript perspective and assumes many things that are not true when using other approaches to calling the endpoints.

    • MV (Jerboa dev)@programming.dev
      link
      fedilink
      arrow-up
      2
      arrow-down
      1
      ·
      4 months ago

      (Author btw)

      Can you expand on this? This was written for Kotlin usage. It automates generating API based on this spec.

      I have no idea what you mean with ‘using other approaches to calling the endpoints’

      Lemmy has only one API. It’s same API used for lemmy-ui.

      This is just a “better” documentation for it.

      The API works for for cloudfare instances too.

      There is also a swagger ui variant

      https://mv-gh.github.io/lemmy_openapi_spec/swagger_ui.html

      • refalo@programming.dev
        link
        fedilink
        arrow-up
        2
        ·
        edit-2
        4 months ago

        This thread sums everything up nicely I think: https://lemmy.ml/post/98675/95459

        And for programming.dev specifically, the API did not work for me when they had CF bot protection turned on (endpoints always returned the “Just a moment…” bot check html), it was only after it was turned off a few days ago that it started working for me, because CF doesn’t like my IP/browser/something and always gives me endless captcha loops. Previously their stance was that bot IPs had to be explicitly whitelisted to be allowed on their server.

        • MV (Jerboa dev)@programming.dev
          link
          fedilink
          arrow-up
          2
          ·
          4 months ago

          I do not see how critisms for the JS API docs are relevant for my openapi documentation.

          This documentation aims to solve all those problems in a language agnostic way. It descibes the endpoints, the request object, the status, the response object, the authentication needed in visual/text. It allows you test it right from the browser, allows you to copy a working curl command, search for endpoints based on keywords, allows you to import the entire spec into postman/alts.

          I ve never had any problems with CF instances but I mostly test with voyager.lemmy.ml

          • refalo@programming.dev
            link
            fedilink
            arrow-up
            2
            ·
            4 months ago

            Yours is a little bit easier to read, but my main problems remain the same. Here’s some initial comments looking at your swagger link from the perspective of a user who is brand new to the lemmy API (and doesn’t use Javascript):

            • I can’t tell what the general flow of the API usage in general is. Am I supposed to login/authorize somehow first? Some common examples, especially in at least one programming language (whether that’s curl or python or whatever) I think would go a long way to help people understand what they’re supposed to do.

            • How do I know if I need to authorize for a particular endpoint?

            • What is the entire URL for any given endpoint? It’s never really explained clearly.

            • What is this “servers” dropdown? What’s the difference between those?

            • Endpoint descriptions are often unhelpful. /user says “Get the details for a person.” It doesn’t tell me this is actually how I’m supposed to find their comments or posts. Nothing tells us this.

            • We have to guess what endpoint we might need for a lot of things. Example: /post/like is also for dislikes, but it doesn’t tell you that. It also never tells you HOW to like or dislike anything, the valid values of score do not appear to be documented. And you’re left to assume that’s the right field to even use for it.

            • What is the content type of the request supposed to be? JSON is never mentioned anywhere.

            • What are these named “parameters”? Is that a query parameter? Why does it say “object” and “(query)”? Does this parameter go in the request body instead? /user shows a parameter called “GetPersonDetails” except in reality this name is (I guess) supposed to be completely ignored, because no part of the request actually uses the string “GetPersonDetails”.

            • Schema is missing for many endpoints, like the request part of /user.

            • What are all these fields under “GetPersonDetails”? Are they all required? Only some? It doesn’t say anything about it.

            • Many of the possible error codes are undocumented.

            There’s probably more but that’s the main stuff I think.