Consider I only know apis are structured data that can be called or modified from within a program, and have no real further knowledge in real use cases nor in networking.

Where should I start from? Should I study backend?

I prefer docs rather than videos.

  • dontblink@feddit.itOPEnglish
    1·
    8 hours ago

    I know some basic Rust (currently at chapter 9) and a little bit of JavaScript.

    I’m trying to work with headless CMSs and that requires some understanding on how APIs work…

    Even tho I wouldn’t want to stick with JS, I don’t really want to dig into frameworks and dependency hells.

    But I like the concept and I need to build a site that grabs some data from an external api, so a headless cms would be my choice to grab the data and structure them there in order to be rendered later in something like a static site generator (I’m quite good at Hugo). Or will learn some basic React and try to build a template on my own there…

    • jonathan7luke@lemmy.mlEnglish
      1·
      5 hours ago

      If you’re building a website, you’ll probably want to stick to Javascript over Rust.

      This MDN article does a pretty good job at introducing the concept of making network requests in Javascript: https://developer.mozilla.org/en-US/docs/Learn_web_development/Core/Scripting/Network_requests. It focuses on the “fetch” API as the tool for making requests, which is the standard way to make network requests in Javascript. There are other tools like Axios that may make things easier, but “fetch” should be fine for your use case.

      Another concept that will be relevant here is asynchronous programming: https://developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Async_JS/Introducing. Basically, there will be some delay between when you make the request and when you get a response. So you’ll need to write your logic in a way that does the “waiting” part correctly.

      One important detail is that most APIs use some form of authentication. So when you’re “grabbing the data” from an external site, the site knows who you are and that you are allowed to access that data. Getting authentication right might be a little tricky, but here is an entry point: https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Authentication. Basically, you’ll need to figure out what authentication strategy your headless CMS is using, and then make sure to safely pass those credentials when making your network requests. If the API(s) you are using are public, you won’t need to worry about this.

      If your goal is primarily to get data from an external source, this should be a good starting point. You don’t necessarily need to get too deep into the backend or even the technical details of things like HTTP or REST. However, if you’re interesting in getting a deeper understanding of Web APIs, the other comment talking about building a skeleton API would be a good exercise.

      • Ephera@lemmy.mlEnglish
        1·
        30 minutes ago

        Sounds to me like they’re not trying to create a website for now, but rather just process some data, which they can later display in a static webpage.

        So, I’m guessing something like this:

        +--------+     +---------+     +----------+
| Static |     | Their   |     | External |
| Web    |---->| Own     |---->| API      |
| Page   |     | Backend |     |          |
+--------+     +---------+     +----------+

        But yes, unless there’s a lot of data to crunch, the design one would usually go for is rather:

        +-----------+     +----------+
| *Dynamic* |     | External |
| Web       |---->| API      |
| Page      |     |          |
+-----------+     +----------+

        So, the data calculations would happen in the user’s browser. You would still need some hosting for that webpage, but there’s lots of free services to put a simple webpage up.

        And yes, when you go with that latter design, then JavaScript would be the typical choice. It’s still possible to do it with Rust, using WebAssembly (e.g. a colleague of mine has built a small statistics webpage which gets data directly from GitHub, using the Leptos framework), but it is definitely the less beaten path.

        Having said all that, frankly, fuck the usual way of doing things. If you’re comfortable with Hugo for frontend work, then I think it’s legit to build a little backend to take over the dynamic part. Better to build a useful project and learn something than to get stuck trying to learn the ‘correct’ path of doing it. Especially if you’d rather learn about Rust than JS.

    • nickwitha_k (he/him)@lemmy.sdf.org
      11·
      6 hours ago

      In that case, my suggestion would be to target implementing a REST API with OpenAPI (formerly Swagger). There are server code generators for both Rust and JS (multiple flavors, I think).

      Basically, the workflow is something like this:

      1. Create your API spec skeleton (YAML or JSON, pick your poison). This will have all of the required sections like info
      2. Pick your first endpoint and define it in the paths section. Probably start with during simple like a GET. This will mean that you mainly have to worry about defining your responses (at minimum HTTP2XX and HTTP4XX, preferably with a catchall error response for HTTP5XX responses) and their schemas.
      3. Run the code generator. This should generate files with stubbed-out definitions for interfaces (or the equivalent for your language of choice) for your response methods. Generally, you do NOT want to add any code to these files as they will be overwritten anytime you update your API spec.
      4. Implement the methods to handle the stubbed out interfaces. Ex. A hello-world interface would likely need to be implemented with a method or function that returns the string “hello world”.

      The reason that I recommend OpenAPI in writing REST APIs is that it helps to layout the API contracts before you even start coding. This helps with keeping typing consistent, give you a clear milestone for implement, and makes creating clients really easy.

      Extra benefit is that OpenAPI is (mostly) language agnostic, so, as long as you have a codegen or some good boilerplate, you can use it for any language, which can give you a safe place to start when learning a new language.

      • Ephera@lemmy.mlEnglish
        1·
        22 minutes ago

        It should be noted that theoretically, we don’t know how this external API is implemented. The vast majority of APIs are REST APIs and with REST APIs, there’s a decent chance that you can download an OpenAPI definition from the server which provides the API.

        REST APIs are basically APIs which use HTTP(S) for transport and then there’s some specific rules how the API should be designed. Often times, these rules are not strictly followed and people still refer to such an API as “REST”, because they assume that any HTTP API is a REST API. But yeah, similarly the guides you’ll find will likely also work with general HTTP APIs.