Add support for resource-level meta.

[beauby]

Untested, but should work. Would love for somebody to provide a few tests, as I am rather busy myself at the moment.
Ref: #1339, #1235.

[kurko]

@gaganawhad following your offer in

I would be happy to try submitting a PR For Resource-level meta. Does that work? Any reason not to ? Let me know! Thanks. #1235

Do you think you could give a hand here? All help is welcome :)

[beauby]

Thanks @kurko! @gaganawhad in case you'd like to give a hand, stuff is happening on my branch.

[beauby]

Waiting for travis, but otherwise looks good to me. @bf4 @NullVoxPopuli, thoughts?

[bf4]

fwiw, there's a test support helper serializable but it wouldn't make things much shorter. Do you think we should test Ruby hashes made from as_json instead of serializable_hash in the future?

[bf4]

Just thinking out loud:

Given that Meta is JSON API object that can appear in a number of places (https://github.com/rails-api/active_model_serializers/blob/master/docs/jsonapi/schema.md#json-api-document-schema), perhaps we can re-use a JSON API meta object? I'm not quite sure how it would look.

Where meta is used:

• topLevel.meta
• topLevel.jsonapi.meta
• resource.meta
• resource.links; link.linkObject.meta
• resource.relationships.meta
• resource.relationships.relationshipToOne.linkage.meta
• resource.relationships.relationshipToMany.linkages; linkage.meta
• errors; error.meta

I'm a little iffy with defining the meta on the serializer, but I'm not sure where it would otherwise go. JSONAPI-Resources puts the meta in the Resource, so, that's good enough for me. Should we consider defining it at the instance level? _serializer_meta?

[beauby]

@bf4 The way I understand the spec, resource-level meta is a legitimate part of a resource's representation (unlike the toplevel meta which contains data related to the document itself, and therefore belongs in the adapter), which in our case is specified by the serializers, so I think it does belong in the serializer.

[bf4]

Should we prefer _meta even though there shouldn't be attribute method conflicts anymore?

[bf4]

@beauby would you mind adding the Serializer::meta method to https://github.com/rails-api/active_model_serializers/blob/master/docs/general/serializers.md ? and maybe reference this PR and its interface in https://github.com/rails-api/active_model_serializers/blob/fce856fc83/docs/jsonapi/schema.md#json-api-document-schema and https://github.com/rails-api/active_model_serializers/blob/fce856fc83/docs/jsonapi/schema.md#definitions

• TODO: we should update the schema.md doc from https://docs.google.com/document/d/1rcrJr0sVcazY2Opd_6Kmv1iIwuHbI84s1P_NzFn-05c/edit?usp=sharing

[beauby]

This should probably be serializaer.class_attribute :_meta.

[beauby]

Resource-level meta tests are expected to fail after last commit, since the handling of the option itself (instance_evaluating the block) is now left to the adapter.

[kurko]

@beauby what does that mean? Expected to fail, which means this PR is WIP?

[beauby]

@kurko I meant that those 2 failing tests were testing implementation-specific stuff that does not exist anymore. I'll update them (or get rid of them if they don't make sense at all anymore) tonight if I get a chance, or tomorrow. Thanks for the ping!

[bf4]

Merged. Added followup issues and addressed more urgent ones

[rafael]

Hey guys - question that I'm not sure from the jsonapi spec. Should the meta be rendered when you include a resource in a request? Let's say you have something like this:

GET /users/:id

=> 

    {
      "id": "e877c0cb-83a9-4058-a033-aa67d3683feb",
      "type": "users",
      "attributes": {
        "username": "test"
      },
      "meta": {
        "test_meta": "test
      }
    }

Should the following request include the meta information for the user?

GET /products/:id?include=users

{
  "data": {
    "id": "ce3402d7-23c8-4c27-bc0f-08b47a5edc39",
    "type": "products",
    "attributes": {
      "title": "asdfsaf"
    },
    "relationships": {
      "user": {
        "data": {
          "id": "6dbf0bb8-b9f5-4658-ab5d-f16663b1f3c2",
          "type": "users"
        }
      }
    }
  },
  "included": [
    {
      "id": "6dbf0bb8-b9f5-4658-ab5d-f16663b1f3c2",
      "type": "users",
      "attributes": {
        "username": "test"
      },
      "meta": {
        "test_meta": "test
      }
    }
  ]
}

[groyoh]

@rafael Since the meta is used for custom information, I guess that's "up to you". Using AMS, I don't think there is a way of removing it or providing a different meta when the resource is in included though.

Since you asked about the spec itself, you would probably get a more appropriate answer at discuss.jsonapi.org. 😉