# Pushing to a relationship that affects resource **URL:** \ **Category:** Uncategorized\ **Created:** [November 9, 2015, 10:54pm UTC](https://discuss.jsonapi.org/t/pushing-to-a-relationship-that-affects-resource/190 "2015-11-09T22:54:49Z")\ **Posts on this page:** 13\ **Page:** 1
**Author:** ![ruz](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.jsonapi.org/ruz/32/113_2.png) [@ruz](https://discuss.jsonapi.org/u/ruz)\ **Post date:** [November 9, 2015, 10:54pm UTC](https://discuss.jsonapi.org/t/pushing-to-a-relationship-that-affects-resource/190/1 "2015-11-09T22:54:50Z")
Hi, Resource of type “rooms” has attribute “people\_in” and relationship “people”. POST operation to `/rooms/1/relationships/people` (self link of the relationship) adds a person to the room. How should correct response look? I want to include the rooms/1 resource into response as it was changed during the request. Can I omit the relationship itself as in “no content” response? ---
**Author:** ![ethanresnick](https://avatars.discourse-cdn.com/v4/letter/e/45deac/32.png) [@ethanresnick](https://discuss.jsonapi.org/u/ethanresnick)\ **Post date:** [November 10, 2015, 4:07pm UTC](https://discuss.jsonapi.org/t/pushing-to-a-relationship-that-affects-resource/190/2 "2015-11-10T16:07:35Z")
> [@ruz](#): > > Resource of type “rooms” has attribute “people\_in” and relationship “people”. POST operation to /rooms/1/relationships/people (self link of the relationship) adds a person to the room. How should correct response look? Can you explain to me the difference between “people\_in” and “people”? Those sound like they should be the same thing to me, which would simplify this case a lot. ---
**Author:** ![ruz](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.jsonapi.org/ruz/32/113_2.png) [@ruz](https://discuss.jsonapi.org/u/ruz)\ **Post date:** [November 10, 2015, 8:52pm UTC](https://discuss.jsonapi.org/t/pushing-to-a-relationship-that-affects-resource/190/3 "2015-11-10T20:52:54Z")
> [@ethanresnick](#): > > Can you explain to me the difference between “people\_in” and “people”? Those sound like they should be the same thing to me, which would simplify this case a lot. Sorry that I was not clear about “people\_in” - it is a counter of people that are in the room. Represents the current size of the “people” relationship. You can argue that it shouldn’t be “materialized” as an attribute, but it is materialized in the API and actually in the DB. My model has also people\_max attribute. It’s very common case if you think it’s not I can demostrate you more examples where it’s handy and sometimes even required to materialize counters. ---
**Author:** ![ethanresnick](https://avatars.discourse-cdn.com/v4/letter/e/45deac/32.png) [@ethanresnick](https://discuss.jsonapi.org/u/ethanresnick)\ **Post date:** [November 11, 2015, 6:29am UTC](https://discuss.jsonapi.org/t/pushing-to-a-relationship-that-affects-resource/190/4 "2015-11-11T06:29:31Z")
> [@ruz](#): > > Sorry that I was not clear about “people\_in” - it is a counter of people that are in the room. Represents the current size of the “people” relationship. Ahh, ok, that makes sense. > [@ruz](#): > > POST operation to /rooms/1/relationships/people (self link of the relationship) adds a person to the room. How should correct response look? Usually, the response would just be a 204. But, since you want to provide extra data about the result… > [@ruz](#): > > I want to include the rooms/1 resource into response as it was changed during the request. Can I omit the relationship itself as in “no content” response? Yes, you can omit the relationship data itself, as in the 204 case, and you should put your extra data (either the full rooms/1 resource or just the updated count) in `meta`. This information must go in `"meta"`, rather than say `"data"` or `"included"`, since those other keys always refer to the relationship’s contents, not the content of the resource that owns the relationship. So the response could simply look like this: ```js 200 OK Content-Type: application/vnd.api+json { "meta": { "people_in": 5 // new count here } } ``` ---
**Author:** ![ruz](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.jsonapi.org/ruz/32/113_2.png) [@ruz](https://discuss.jsonapi.org/u/ruz)\ **Post date:** [December 15, 2015, 4:56pm UTC](https://discuss.jsonapi.org/t/pushing-to-a-relationship-that-affects-resource/190/5 "2015-12-15T16:56:53Z")
Hm. I missread your reply. Why meta? Is it because of “full linkage requirement” of compound documents or because of some other reason I don’t see? ---
**Author:** ![ethanresnick](https://avatars.discourse-cdn.com/v4/letter/e/45deac/32.png) [@ethanresnick](https://discuss.jsonapi.org/u/ethanresnick)\ **Post date:** [December 15, 2015, 8:21pm UTC](https://discuss.jsonapi.org/t/pushing-to-a-relationship-that-affects-resource/190/6 "2015-12-15T20:21:19Z")
> [@ruz](#): > > Why meta? Is it because of “full linkage requirement” of compound documents or because of some other reason I don’t see? It’s simply because the response is coming from a relationship URI and, at a relationship URI, `"data"` always contains the resource identifier objects of the _relationship’s targets_, and `"included"` always represents the full resources for those targets. But you want to include information not about the targets of the relationship (i.e. the people) but about the _owner_ of the relationship (i.e. the room). And because there’s no standard place for that, it has to go in `"meta"`. ---
**Author:** ![ruz](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.jsonapi.org/ruz/32/113_2.png) [@ruz](https://discuss.jsonapi.org/u/ruz)\ **Post date:** [December 16, 2015, 11:04am UTC](https://discuss.jsonapi.org/t/pushing-to-a-relationship-that-affects-resource/190/7 "2015-12-16T11:04:40Z")
Understood 😢 Consider adjusting spec that server MAY send included with whatever content it wants in any response 🙂 It would be so handy to send out objects to client that were “side affected” by the operation. As you understand elements in the relationship even have no pointer to this particular room, so you can not request to include the room from the client side. Going to put included into meta for now and customize client’s code to understand such includes in any response to update client’s resources cache. ---
**Author:** ![ethanresnick](https://avatars.discourse-cdn.com/v4/letter/e/45deac/32.png) [@ethanresnick](https://discuss.jsonapi.org/u/ethanresnick)\ **Post date:** [December 16, 2015, 7:53pm UTC](https://discuss.jsonapi.org/t/pushing-to-a-relationship-that-affects-resource/190/8 "2015-12-16T19:53:42Z")
Sounds good @ruz! Eventually, I think your use case will be addressed by [#795](https://github.com/json-api/json-api/issues/795), which could allow you to get the updated room in the same response. ---
**Author:** ![ruz](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.jsonapi.org/ruz/32/113_2.png) [@ruz](https://discuss.jsonapi.org/u/ruz)\ **Post date:** [December 16, 2015, 8:35pm UTC](https://discuss.jsonapi.org/t/pushing-to-a-relationship-that-affects-resource/190/9 "2015-12-16T20:35:15Z")
I don’t see how “multiple transactional updates in one request” related to this. What I suggest and expected to be allowed is for server to add any objects to “includes”. Client posts a comment to an article #123, this is one operation and well defined in the spec, but as side effect of this action server also updates comments\_counter attribute on the article #123. What I want is to free client from repeating this operation on the article object and I want to do this by including up to date article representation into response of “post a comment” operation. Spec already have an exception to “full linkage” rule - sparse fields. Maybe this requirement is not that good afterall. ---
**Author:** ![ethanresnick](https://avatars.discourse-cdn.com/v4/letter/e/45deac/32.png) [@ethanresnick](https://discuss.jsonapi.org/u/ethanresnick)\ **Post date:** [December 17, 2015, 2:56am UTC](https://discuss.jsonapi.org/t/pushing-to-a-relationship-that-affects-resource/190/10 "2015-12-17T02:56:25Z")
The connection to #795 is that one operation from #795 would be a “fetch” so you could update the relationship and then get the new version of the owning resource (the room) in a single request/response. > [@ruz](#): > > What I suggest and expected to be allowed is for server to add any objects to “includes”. To me, this feels like it would make the meaning of `"included"` a bit too confusing/open-ended, but it’s an interesting idea. Can you open an issue about it on Github? I’m curious what others think… ---
**Author:** ![jlangley](https://avatars.discourse-cdn.com/v4/letter/j/9e8a1a/32.png) [@jlangley](https://discuss.jsonapi.org/u/jlangley)\ **Post date:** [August 2, 2016, 10:50pm UTC](https://discuss.jsonapi.org/t/pushing-to-a-relationship-that-affects-resource/190/11 "2016-08-02T22:50:10Z")
> [@ethanresnick](#): > > This information must go in “meta”, rather than say “data” or “included”, since those other keys always refer to the relationship’s contents, not the content of the resource that owns the relationship. Why isn’t it permitted for the response to look like this?: > [@](#): > > 200 OK > Content-Type: application/vnd.api+json > > { > “data”: [ > // _updated relationship (primary data)_ > {“type”: “people”, “id”: “person1”}, > {“type”: “people”, “id”: “person2”}, > {“type”: “people”, “id”: “person3”}, > {“type”: “people”, “id”: “person4”}, > {“type”: “people”, “id”: “person8”} > ], > “included”: [ > { // _resource related to the primary data_ > “type”: “people”, > “id”: “person8”, > “relationships”: { > “inRoom”: { > “data”: {“type”: “rooms”, “id”: “1”} // _full linkage for the room_ > } > } > }, > { > // _fully linked resource_ > “type”: “rooms”, > “id”: “1”, > “attributes”: { > “people\_in”: 5 // _new count here_ > } > } > ] > } Or is it that such a response **is** _allowed_ but just is not suitable for @ruz because the updated relationship is present (rather than omitted) and because the person has a relationship to the room (which @ruz seems not to want for some reason)? ---
**Author:** ![ruz](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.jsonapi.org/ruz/32/113_2.png) [@ruz](https://discuss.jsonapi.org/u/ruz)\ **Post date:** [August 3, 2016, 10:59pm UTC](https://discuss.jsonapi.org/t/pushing-to-a-relationship-that-affects-resource/190/12 "2016-08-03T22:59:52Z")
Read closely “full linkage requirement”. Response 200 would’ve worked for me just fine, but neither 200 nor 204 allow you to send an include not referenced in data or another include because of the requirement. ---
**Author:** ![jlangley](https://avatars.discourse-cdn.com/v4/letter/j/9e8a1a/32.png) [@jlangley](https://discuss.jsonapi.org/u/jlangley)\ **Post date:** [August 4, 2016, 7:51am UTC](https://discuss.jsonapi.org/t/pushing-to-a-relationship-that-affects-resource/190/13 "2016-08-04T07:51:01Z")
> [@ruz](#): > > Read closely “full linkage requirement” Can you show exactly which section of the spec you think prevents this? I based my suggestion on [this](http://jsonapi.org/format/#document-compound-documents) which states: > [@](#): > > Compound documents require “full linkage”, meaning that every included resource MUST be identified by at least one resource identifier object in the same document. These resource identifier objects could either be primary data or represent resource linkage contained within primary or included resources. I _think_ my suggestion complies - the included person is referenced by a resource identifier in the primary data, and the included room is referenced by a resource identifier in a resource linkage (data object in a relationship object) in an included resource (the included person).