Matteo Ferrando
Matteo Ferrando
I was imagining it like if you're returning as the main the `appointment`, then in the `relationships` there would be `services`, and add in the `services` meta some more attributes.
> Are you running into this issue specifically? No, I was just curious. You're right, not worth implementing yet.
We have the same case (obviously not for pets) and handled it with a meta too. The thing is that we didn't include it in the `GET` it was just...
And what if you had a `service` to be done to pets `1,2` and another `service` for pets `2,3`. Which I understand your current DB schema permits.
But what would the `meta` be to represent it?
Maybe the `meta` goes in the `included` instead of the `relationships` part for this?
[They say it's ok to use the `meta` **inside** the `data` part](http://discuss.jsonapi.org/t/metadata-about-relationships/86/2)
The cleaner way I see is adding it in the `included` [resource object](http://jsonapi.org/format/upcoming/#document-resource-objects), but you would have to include the relationships always.
``` js { "data": { "type": "appointment", "attributes": { // info }, "relationships": { "services": { "data": [{ "type": "service", "id": 1}, { "type": "service", "id": 2}] } } },...
> Are you opposed to following the spec as-is for the time being with the option to add more meta functionality down the road? You propose to leave this as...