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.”

  • @PeriodicallyPedantic@lemmy.ca
    3•5 months ago

    Imagine you’re writing a CRUD API, which is pretty common.
    If null attributes aren’t included in the payload, and someone does an update (typically a PATCH), how do you know which fields should be nulled out and which should be ignored?

    I agree for many cases the two are semantically equivalent, but it’s common enough to not have them be equivalent that I’m surprised that it causes arguments

    • @kakes@sh.itjust.works
      1•5 months ago

      For an API there should always be a version parameter/endpoint, imho.

      Edit for further context: Ideally, a parameter.

      • @PeriodicallyPedantic@lemmy.ca
        2•5 months ago

        I wasn’t taking about new fields. I was talking about resource partial updates (eg PATCH, or commonly the U in CRUD).

        If you just want to update a single field on a resource with 100 fields, rather than GETting the entire resource, updating the single field, and PUTting whole thing back, just do a PATCH with the single field.

        Likewise if you’re POSTing a resource that has nullable fields, but the default value isn’t null, how do you indicate that you want the default value for a given field? Do you have to first query some metadata API? That doesn’t seem ideal, when this existing pattern exists