'reserve attributes in top level of resource object'

[pmccarren]

I'd like to bring some attention to json-api/json-api#588 and specifically commit json-api/json-api@c1b320f. This was recently merged into the spec. I think it warrants a top level struct named something like Resource. At this point in time this struct would contain id, type, attributes.

Thoughts?

[sharpner]

Hi thanks for the update. Our library is currently compatible with the release candidate 3 of jsonapi.org. The json-api/json-api#588 you referenced has still many open tickets, so believe it's safe to assume that this will change in any way until the rc4 ;-). Therefore I suggest not to implement features as soon as they are merged in the master. Additionally, I don't believe that there are any clients implementing those master features at the moment.

[wwwdata]

well, what they changed and already merged for now is the change to put attributes of a resource object into an attributes sub-object like this

{
  "data": {
    "type": "articles",
    "id": "1",
    "attributes": {
      // ... attributes of this article
    }
  }
}

so, only type and id are directly in the data object, everything else is in the attributes sub-object. I guess this makes sense if you have a struct field that is interfering with the already reserved names from jsonapi. I don't know, this would currently only be type that is not usable. But maybe they do this for the future, that it's easy to add more reserved fields.

[wwwdata]

version 1.0 is out now, and the behavior is now like described in this ticket. I think I will start working on this tomorrow.

[wwwdata]

I started on this feature and now there is something tricky we have to decide on:

Everything except the type and the id field now goes into the attributes object in the json. To determine the ID of the struct, there is the GetID() method of the MarshalIdentifier interface. So far so good, but do we now expect from the user, to json ignore flag the ID field inside his struct, so that it does not get get into the attributes object again? Or do we look for a field with the name ID or Id and just ignore it?

Example:

type User struct {
    ID       int 
    Name     string
    Password string `json:"-"`
}

this would now result into:

<map[string]interface {} | len:1>: {
            "data": {
                "attributes": {"id": 100, "name": "Nino"},
                "id": "100",
                "type": "users",
            },
        }

But with the ignore flag like this:

type User struct {
    ID       int `json:"-"`
    Name     string
    Password string `json:"-"`
}

the ID field will be ignored and the result is like it is expected:

<map[string]interface {} | len:1>: {
            "data": {
                "attributes": {"name": "Nino"},
                "id": "100",
                "type": "users",
            },
        }

The question now is: do we skip this field per defauilt? It may also be a api2go users intention to have a field named id inside the attributes object. The id outside of this object can be something entirely different, because it is like previously mentioned, determined by the GetID() method.

Any thoughts about this? Currently I t hink we shouldn't automatically remove the id field and let the user decide, although this behaviour might cause some small confusions at first.

[pmccarren]

I vote to not automatically remove it because the reasoning to use the attributes struct in the first place is to avoid collisions with jsonapi reserved keys. I suppose this same question can be raised with the type key as well..