Sideposting verbs do not seem to comply with JSONAPI specification

[jlandic]

Hi,

When attempting to persist relationships, the addition of the HTTP verb in the method field of the relationship's data payload may not be strictly JSONAPI-compliant.

As per the specification:

A resource object MUST contain at least the following top-level members:

id type Exception: The id member is not required when the resource object originates at the client and represents a new resource to be created on the server.

In addition, a resource object MAY contain any of these top-level members:

attributes: an attributes object representing some of the resource’s data. relationships: a relationships object describing relationships between the resource and other JSON:API resources. links: a links object containing links related to the resource. meta: a meta object containing non-standard meta-information about a resource that can not be represented as an attribute or relationship.

This additional field provokes errors in some server-side implementations, as a non-valid data representation.

Would there be a way to deal with sideposting in another fashion? Or allow the developer to choose whether or not to enable this "Graphiti-only" behaviour?

[vitorreis]

+1

[richmolj]

Hi @jlandic and @vitorreis !

We put the method alongside the Resource Identifier in the relationships payload.

“resource identifier object” MUST contain type and id members.

A “resource identifier object” MAY also include a meta member, whose value is a meta object that contains non-standard meta-information.

This doesn't seem to disallow an additional optional key of method. We've talked to the JSON:API guys and I think sideposting will eventually get into the spec in some form. I haven't heard it brought up as a backwards-incompatibility.

I hear you that some server-side implementations would reject this. JSON:API doesn't have this functionality (persist a graph of objects in a single request). So basically if you aren't using Graphiti server-side, then you aren't able to use this feature - because this feature isn't available in any JSON:API server implementation except for Graphiti.

We might be able to improve the picture of saving relationships to /relationships URLs, which would require a separate request. This is not needed in Graphiti with sideposting, and I view these as the worst part of JSON:API, but may be needed (or at least helpful) for other server-side implementations.

Does all that make sense?

[jlandic]

Hi @richmolj !

Thanks for your answer. It does indeed make sense to me. I reckon the server-side implementation has no reason to reject such a resource identifier in the end, so I guess it's worth a discussion with their maintainers. In the mean time I'll monkey-patch the request server-side to remove the key.

However, regarding this rule:

A “resource identifier object” MAY also include a meta member, whose value is a meta object that contains non-standard meta-information.

If I understand correctly, it might be preferable to nest the method key inside a meta object, like so:

{
  "id": "1",
  "types": "resources",
  "meta": {
    "method": "update"
  }
}

What do you think?

[Petercopter]

This is a problem when using Spraypaint with http://jsonapi-resources.com on the backend as well, the request gets rejected because of the unknown key. I ended up using Hashie DeepLocate to remove the method parameter in a before_action to get things working.