omitempty for primary ID about jsonapi HOT 4 CLOSED

As a client this is definitely a valid scenario. You construct the entity client side, and when the server saves the entity it assigns and returns the id.

This library was originally abstracted out of a project where our original use case was a go jsonapi server. As such, we only considered the server use case for the id field.

With that being said it should not be that hard to add the omitempty feature to the id annotation. If you want to take a stab at it, I'd be happy to review your pull request. Otherwise it may be a few weeks before I can spend time on this.

from jsonapi.

For me its as simple as adding omitempty to the ID field of Node, but I'm not sure of the ramifications of this. Do you think this would negatively affect any usage? I haven't read the spec carefully enough to be 100% certain...

If you think that's all it takes I'd be happy to make that PR.

from jsonapi.

Initially I thought we would allow the developer to annotate their structs' id field with omitempty. However (as far as I'm aware) I don't see why you would ever want to transmit an empty string id. The example below is JSONAPI spec complaint (as the ID is a string), but not sensible to transmit:

{
    "data": {
        "type": "foo",
        "id": "",
        "attributes": {...}
    }
}

Which means it is seemingly OK to annotate Node's ID field with a vanilla json omitempty.

Thoughts @shwoodard ?

from jsonapi.

Right, and the other issue is even if we could just annotate jsonapi:"primary,type,omitempty", because Node doesn't have omitempty on ID, it would still transmit a blank ID. So eventually we'd have to get there anyways. :)

from jsonapi.