{"action":"closed","issue":{"url":"https://api.github.com/repos/CPAN-API/cpan-api/issues/402","repository_url":"https://api.github.com/repos/CPAN-API/cpan-api","labels_url":"https://api.github.com/repos/CPAN-API/cpan-api/issues/402/labels{/name}","comments_url":"https://api.github.com/repos/CPAN-API/cpan-api/issues/402/comments","events_url":"https://api.github.com/repos/CPAN-API/cpan-api/issues/402/events","html_url":"https://github.com/CPAN-API/cpan-api/issues/402","id":63894627,"number":402,"title":"Return more info with reverse deps search","user":{"login":"rwstauner","id":142719,"avatar_url":"https://avatars.githubusercontent.com/u/142719?v=3","gravatar_id":"","url":"https://api.github.com/users/rwstauner","html_url":"https://github.com/rwstauner","followers_url":"https://api.github.com/users/rwstauner/followers","following_url":"https://api.github.com/users/rwstauner/following{/other_user}","gists_url":"https://api.github.com/users/rwstauner/gists{/gist_id}","starred_url":"https://api.github.com/users/rwstauner/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/rwstauner/subscriptions","organizations_url":"https://api.github.com/users/rwstauner/orgs","repos_url":"https://api.github.com/users/rwstauner/repos","events_url":"https://api.github.com/users/rwstauner/events{/privacy}","received_events_url":"https://api.github.com/users/rwstauner/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"milestone":null,"comments":1,"created_at":"2015-03-24T03:25:43Z","updated_at":"2016-03-05T13:42:14Z","closed_at":"2016-03-05T13:42:14Z","body":"ranguard tricked me into saying\r\n\r\n> i think we need a nested query to do the filtering, but adding the column should be easy\r\n\r\nand then quoted me in CPAN-API/metacpan-web#1292\r\n\r\nSo I looked into it a little more...\r\nThe `/requires/distribution/$dist` ui uses the `/search/reverse_dependencies/$dist` api endpoint,\r\nwhich returns a list of releases in the format of ES search results.\r\nUnfortunately the \"relationship\" info is lost in the response.\r\nIt would really make things easier on the receiver side if extra information was returned.\r\n\r\nFirst, the api uses a list of modules (those contained in the specified dist) to build the search results.\r\nIf the response included that list of modules, that would make searching for the relationships simpler.\r\nOtherwise you really should be making another api call to get that list (of module names).\r\nWhile the search results is in a predefined format, it's a top level hash, so there is room that we could jam in this \"extra\" info.  It might be worth considering if we wanted to use a generic top level key for \"extra data\" that we might reuse in other responses.\r\n\r\nAdditionally, we could do some relationship aggregation on the server side and return that with the result, since, if we don't, it's likely that the client will have to do it.\r\nFor each release in our search results, we could search it's list of relationships, find the relevant ones (matching one of the module names in our list), then do a \"max\" on the relationship phase and type\r\nand return a summary for each release.  We could return this little hash of \"phase\" and \"type\" in with each release since each \"hit\" entry is a hash of \"_source\", \"_id\", etc.\r\n\r\nAny thoughts? "}}