Meme transcription: Panel 1. Two images of JSON, one is the empty object, one is an object in which the key name maps to the value null. Caption: “Corporate needs you to find the difference between this picture and this picture”

Panel 2. The Java backend dev answers, “They’re the same picture.”

  • @sik0fewl@lemmy.ca
    link
    fedilink
    86 months ago

    Ya, having null semantics is one thing, but having different null and absent/undefined semantics just seems like a bad idea.

    • @Username@feddit.de
      link
      fedilink
      396 months ago

      Not really, if absent means “no change”, present means “update” and null means “delete” the three values are perfectly well defined.

      For what it’s worth, Amazon and Microsoft do it like this in their IoT offerings.

      • @expr@programming.dev
        link
        fedilink
        86 months ago

        Zalando explicitly forbids it in their RESTful API Guidelines, and I would say their argument is a very good one.

        Basically, if you want to provide more fine-grained semantics, use dedicated types for that purpose, rather than hoping every API consumer is going to faithfully adhere to the subtle distinctions you’ve created.

        • @masterspace@lemmy.ca
          link
          fedilink
          English
          4
          edit-2
          6 months ago

          They’re not subtle distinctions.

          There’s a huge difference between checking whether a field is present and checking whether it’s value is null.

          If you use lazy loading, doing the wrong thing can trigger a whole network request and ruin performance.

          Similarly when making a partial change to an object it is often flat out infeasible to return the whole object if you were never provided it in the first place, which will generally happen if you have a performance focused API since you don’t want to be wasting huge amounts of bandwidth on unneeded data.

          • @expr@programming.dev
            link
            fedilink
            06 months ago

            The semantics of the API contract is distinct from its implementation details (lazy loading).

            Treating null and undefined as distinct is never a requirement for general-purpose API design. That is, there is always an alternative design that doesn’t rely on that misfeature.

            As for patches, while it might be true that JSON Merge Patch assigns different semantics to null and undefined values, JSON Merge Patch is a worse version of JSON Patch, which doesn’t have that problem, because like I originally described, the semantics are explicit in the data structure itself. This is a transformation that you can always apply.

            • @masterspace@lemmy.ca
              link
              fedilink
              English
              2
              edit-2
              6 months ago

              No there isn’t.

              Tell me how you partially change an object.

              Object User :

              { Name: whatever, age: 0}

              Tell me how you change the name without knowing the age. You fundamentally cannot, meaning that you either have to shuttle useless information back and forth constantly so that you can always patch the whole object, or you have to create a useless and unscalable number of endpoints, one for every possible field change.

              As others have roundly pointed out, it is asinine to generally assume that undefined and null are the same thing, and no, it flat out it is not possible to design around that, because at a fundamental level those are different statements.

              • @expr@programming.dev
                link
                fedilink
                -16 months ago

                As I already said, it’s very simple with JSON Patch:

                [
                  { *op": "replace", "path": "/Name™, "value": "otherName"}
                ]
                

                Good practice in API design is to permissively accept either undefined or null to represent optionality with same semantics (except when using JSON Merge Patch, but JSON Patch linked above should be preferred anyway).

                • @masterspace@lemmy.ca
                  link
                  fedilink
                  English
                  -1
                  edit-2
                  6 months ago

                  I.e. waste a ton of bandwidth sending a ridiculous amount of useless data in every request, all because your backend engineers don’t know how to program for shit.

                  Gotcha.

                  • @expr@programming.dev
                    link
                    fedilink
                    26 months ago

                    It’s about making APIs more flexible, permissive, and harder to misuse by clients. It’s a user-centric approach to API design. It’s not done to make it easier on backend. If anything, it can take extra effort by backend developers.

                    But you’d clearly prefer vitriol to civil discourse and have no interest in actually learning anything, so I think my time would be better spent elsewhere.

      • @eyeon@lemmy.world
        link
        fedilink
        36 months ago

        it does feel ambiguous though as even what you outlined misses a 4th case. if null means delete, how do I update it to set the field to null?

      • lad
        link
        fedilink
        English
        -16 months ago

        Except, if you use any library for deserialization of JSONs there is a chance that it will not distinguish between null and absent, and that will be absolutely standard compliant. This is also an issue with protobuf that inserts default values for plain types and enums. Those standards are just not fit too well for patching

        • @masterspace@lemmy.ca
          link
          fedilink
          English
          26 months ago

          I’ve never once seen a JSON serializer misjudge null and absent fields, I’ve just seen developers do that.

          • lad
            link
            fedilink
            English
            06 months ago

            Well, Jackson before 2.9 did not differentiate, and although this was more than five years ago now, this is somewhat of a counter example

            Also, you sound like serializers are not made by developers

            • @masterspace@lemmy.ca
              link
              fedilink
              English
              0
              edit-2
              6 months ago

              Bruh, there’s a difference between the one or two serializing packages used in each language, and the thousands and thousands and thousands of developers who miscode contracts after that point.

      • @0x0@programming.dev
        link
        fedilink
        16 months ago

        It gets more fun if we’re talking SQL data via C API: is that 0 a field with 0 value or an actual NULL? Oracle’s Pro*C actually has an entirely different structure or indicator variables just to flag actual NULLs.