• HubertManne@moist.catsweat.com
    link
    fedilink
    arrow-up
    2
    ·
    1 hour ago

    This is sorta funny for me because as a non cs major who went into it it seems like all the api’s I work with are called rest apis and I was always wondering what a non rest api would be.

  • freagle@lemmygrad.ml
    link
    fedilink
    English
    arrow-up
    2
    ·
    2 hours ago

    Honestly this is completely ridiculous. Hypertext using HTML constraints is absolutely insufficient for representing application state. It’s the wrong tool for the job and always has been, because it conflates document structure with semantic meaning.

    Said another way, HTML cannot be relied on to capture a representation of application state.

    The reason REST doesn’t use HTML in most contexts is because applications don’t use HTML in most contexts anymore.

    Demanding that application representation use a specific encoding strategy is ridiculous and misses the point entirely, which is that HTTP is no longer the right protocol for the job.

    • Slotos@feddit.nl
      link
      fedilink
      arrow-up
      2
      ·
      1 hour ago

      While HTML is hypertext markup language, hypertext is not HTML.

      Hypertext doesn’t imply a specific encoding strategy, it implies semantics - data contains links to related data. If you want to encode it in protobufs - you do you, REST explicitly calls for freedom in this regard.

      To paraphrase yourself, ranting about HTML as if it was a requirement for REST is ridiculous and misses the point entirely.

      PS: HTML is not a protocol.

  • vzq@lemmy.world
    link
    fedilink
    arrow-up
    11
    arrow-down
    6
    ·
    3 hours ago

    This is all very “old man yells at cloud”.

    Interesting historical note, but things change.

    • Dunstabzugshaubitze@feddit.org
      link
      fedilink
      arrow-up
      14
      arrow-down
      1
      ·
      3 hours ago

      I’d Agree in most cases, but not in this one.

      Rigor in definitions allows us to express a lot of complex things in a compact form. this allows us to treat “Cars” as something different than “Motorcycles” while both a motorized vehicles.

      the same is true for REST-API and other API-Types, while all of them are just a means to allow services to exchange data, they tell us a lot about how this exchange happens and what to expect, but only if we use the words in a way that they represent the concept they were meant to represent. Otherwise we end up with meaningless buzz words like “rest”, “agile”, “scrum”, “artificial intelligence” and so forth, instead of meaningful terms found in the jargon of other engineering disciplines like “magnetism”, “gravity” or “motor”.

      • frezik@midwest.social
        link
        fedilink
        arrow-up
        8
        arrow-down
        3
        ·
        2 hours ago

        We’re well past that. I would probably care more if the original idea behind REST solved a real problem, but it doesn’t. It’s architecture astronaut stuff.

        If REST is just about using HTTP verbs and status codes smarter, and sending the payload in JSON, I’m good to leave it at that. It’s useful.

        • vzq@lemmy.world
          link
          fedilink
          arrow-up
          5
          ·
          2 hours ago

          Besides, the original definition is not reflective of real world needs - which is why it’s morphed to something else.

      • sushibowl@feddit.nl
        link
        fedilink
        arrow-up
        3
        ·
        2 hours ago

        Rigor in definitions allows us to express a lot of complex things in a compact form. this allows us to treat “Cars” as something different than “Motorcycles” while both a motorized vehicles.

        Meh. There’s plenty of room in the gray zone between “car” and “motorcycle” where things like this or this can exist. The botanical world has worked very hard to create rigorous definitions of fruits and vegetables only to be completely ignored by cooks. The culinary world in general has done just fine for centuries without rigorously specifying whether taco’s are sandwiches and cereal is a soup.

        As long as it is generally understood what people mean by a word when they use it everything will be mostly fine. REST is an understood term, whether the inventor of the term meant something else by it is immaterial.

        • Dunstabzugshaubitze@feddit.org
          link
          fedilink
          arrow-up
          2
          ·
          edit-2
          2 hours ago

          my problem is not with words changing there meaning its with words losing meaning.

          rest api today means any api ontop of http where response bodies are json, but nothing more, we can’t get much more general when talking about web apis than that, “rest” is almost meaningless and we don’t have a new word describing APIs that adhere to the constraints of what restful meant, but those are a useful tool for building web applications that can easily be used by a web browser. no matter if you like fielding-rest-style-apis or not, you lost the ability to call them by a name and gained murky mumbo jumbo for it.

          • MagicShel@lemmy.zip
            link
            fedilink
            English
            arrow-up
            2
            ·
            2 hours ago

            I’m my observation, as a nearly-30-year-vet in the field, it’s due to the same factors as always. The technology doesn’t enforce the standard. So people do any fucking thing they want because they honestly don’t know any better.

            I’m working on an app right now. On one of the controllers there is a single endpoint, out of about 30 (which should fucking tell you something right there) that conforms to restful standards. Every single other one of them is wrong. Because folks didn’t know better and leaders didn’t lead/teach/know any better themselves.

    • Slotos@feddit.nl
      link
      fedilink
      arrow-up
      3
      ·
      3 hours ago

      A cargo cult doesn’t change airplanes by building mock runways - they rather miss the point entirely.