{"action":"created","issue":{"url":"https://api.github.com/repos/rails-api/active_model_serializers/issues/1333","repository_url":"https://api.github.com/repos/rails-api/active_model_serializers","labels_url":"https://api.github.com/repos/rails-api/active_model_serializers/issues/1333/labels{/name}","comments_url":"https://api.github.com/repos/rails-api/active_model_serializers/issues/1333/comments","events_url":"https://api.github.com/repos/rails-api/active_model_serializers/issues/1333/events","html_url":"https://github.com/rails-api/active_model_serializers/issues/1333","id":117291170,"number":1333,"title":"Include option for associations in serializers","user":{"login":"oyeanuj","id":9633371,"avatar_url":"https://avatars.githubusercontent.com/u/9633371?v=3","gravatar_id":"","url":"https://api.github.com/users/oyeanuj","html_url":"https://github.com/oyeanuj","followers_url":"https://api.github.com/users/oyeanuj/followers","following_url":"https://api.github.com/users/oyeanuj/following{/other_user}","gists_url":"https://api.github.com/users/oyeanuj/gists{/gist_id}","starred_url":"https://api.github.com/users/oyeanuj/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/oyeanuj/subscriptions","organizations_url":"https://api.github.com/users/oyeanuj/orgs","repos_url":"https://api.github.com/users/oyeanuj/repos","events_url":"https://api.github.com/users/oyeanuj/events{/privacy}","received_events_url":"https://api.github.com/users/oyeanuj/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/rails-api/active_model_serializers/labels/S:%20Needs%20Team%20Discussion","name":"S: Needs Team Discussion","color":"5319e7"},{"url":"https://api.github.com/repos/rails-api/active_model_serializers/labels/V:%200.10.x","name":"V: 0.10.x","color":"bfd4f2"}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":17,"created_at":"2015-11-17T06:20:08Z","updated_at":"2016-07-12T15:46:22Z","closed_at":null,"body":"I am migrating from 0.9.3 to 0.10.0-rc3 to take advantage of json-api. Based on the current docs, it seems if I want the association's data as part of the response, I will have to specify it as part of 'include' option when calling render in the controller. \r\n\r\nIs there a way to specify this in the serializer instead of the controller, so that I can specify it once and everytime I render that serializer, those associations are included in the json-api by default (instead of having to specify it every time I render that object)? That seemed to be the default behavior in the 0.9.x \r\n\r\nTLDR: Instead of \r\n```ruby\r\n# posts_controller.rb\r\nrender @post, include: ['author', 'metrics', 'media']\r\n```\r\nsomething like this:\r\n```ruby\r\n# post_serializer.rb\r\n\r\nhas_many :metrics #or included by default which would be ideal\r\nhas_many :media, only: [title]\r\nhas_many :publishers, except: [publisher_bio]\r\n\r\n# or even\r\nhas_one :author, include: true \r\n\r\n```\r\n\r\nMaybe it is already there and I missed it. Either way, I would love some clarity. \r\n\r\nThanks!\r\n"},"comment":{"url":"https://api.github.com/repos/rails-api/active_model_serializers/issues/comments/232090489","html_url":"https://github.com/rails-api/active_model_serializers/issues/1333#issuecomment-232090489","issue_url":"https://api.github.com/repos/rails-api/active_model_serializers/issues/1333","id":232090489,"user":{"login":"iMacTia","id":2527520,"avatar_url":"https://avatars.githubusercontent.com/u/2527520?v=3","gravatar_id":"","url":"https://api.github.com/users/iMacTia","html_url":"https://github.com/iMacTia","followers_url":"https://api.github.com/users/iMacTia/followers","following_url":"https://api.github.com/users/iMacTia/following{/other_user}","gists_url":"https://api.github.com/users/iMacTia/gists{/gist_id}","starred_url":"https://api.github.com/users/iMacTia/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/iMacTia/subscriptions","organizations_url":"https://api.github.com/users/iMacTia/orgs","repos_url":"https://api.github.com/users/iMacTia/repos","events_url":"https://api.github.com/users/iMacTia/events{/privacy}","received_events_url":"https://api.github.com/users/iMacTia/received_events","type":"User","site_admin":false},"created_at":"2016-07-12T15:46:22Z","updated_at":"2016-07-12T15:46:22Z","body":"I would like to 👍 +1 on this one and to trigger the \"Team Discussion\" needed to progress on this :)\r\nJust finished chatting about it with @bf4 and @NullVoxPopuli in #1828, this would be a really nice and useful addition to those sticking with the good old standard JSON adapter.\r\n\r\nI understand the concerns around this feature, as @bf4 already pointed out:\r\n\r\n> Bear in mind, that AMS is oriented to using the semantics of jsonapi.org/format/ which doesn't map well to your implementation. The AMS way to do that would be to use default params in your render call, rather than patch the serializer. i.e. something like \r\n\r\n```ruby\r\n    render json: post, include: [:metrics, :media, :publishes, :author],\r\n        fields: { media: [:title], publishers: (PublisherSerializer._attributes - :publisher_bio) }.\r\n```\r\n\r\n> That would have the same effect, assuming you're using JSON API, but not require the serializer only know how to map attributes and relationships, but not how you want to render them.\r\n\r\nAnd @NullVoxPopuli added:\r\n\r\n> since JSON API is the most full-featured, we're based all the adapter functionality off of that. We also want to ensure the apis are the same in all adapters, (which we currently don't have) -- so this feature request may be implemented post 1.0\r\n\r\n> [...] Having different options between the adapters is confusing. All adapters should have the same options. Otherwise things are too coupled to specific implementations.\r\n\r\n\r\nSo here we are, do you think we can have a chat about it and try to find an implementation that would suite everyone? I made a PR in the past to add this capability:\r\nhttps://github.com/rails-api/active_model_serializers/compare/master...iMacTia:master\r\nBut it only works with the JSON adapter, not for the JSON API one.\r\n\r\n==== Discussion time! ====\r\n\r\nFirst of all, I would like to reply to @bf4 because this looks to me like the most important decision in this matter. I had a quick read about the jsonapi semantics and I think this is the paragraph concerning our case: http://jsonapi.org/format/#fetching-includes\r\nAs you can read:\r\n\r\n> An endpoint MAY return resources related to the primary data by default.\r\n> An endpoint MAY also support an include request parameter to allow the client to customize which related resources should be returned.\r\n\r\nMy interpretation is that having default nested resources and don't allowing a customisation through the `include` parameter is legit according to the document. That said, if I have the same serialiser used in many controllers or embedded in many other resources, it could be hard for me to copy-and-paste the `include` option in all controller actions.\r\n\r\nThe solution to this (edge?) case is to allow people to specify at serialiser level which associations will ALWAYS be included, regardless of the context.\r\n\r\nI really think we should all agree on this before going forward, would love to hear your thought on this :)"}}
{"actor":{"display_login":"iMacTia"}}