omitempty for primary ID

[mitchellh]

I'm using jsonapi to construct jsonapi documents as an API client and when marshaling a resource for creation I'd like to omit the "id" since the implementation I'm using requires that (and appears spec compliant as far as I can tell).

To do this at the moment I have to reimplement OnePayload to have omitempty on the ID manually.

[aren55555]

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.

[mitchellh]

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.

[aren55555]

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 ?

[mitchellh]

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. :)