Requesting partial responses from GitHub API (selecting output/response fields)

Does the GitHub API provide a way of requesting partial responses by selecting/limiting the fields returned in an API call?

APIs like Blogger and Google Drive allow one to specify a set of fields that should be included in the response (e.g. via the fields parameter). This is handy for trimming down unnecessary network bandwidth when retrieving large datasets.

Does the GitHub API provide a similar functionality (e.g. retrieving a list of repos that only contains the repo names, excluding all other fields like id, owner, collaborators_url, teams_url, hooks_url, …)? I looked through the documentation but could not find anything useful.

As an example, if I request my own repos using the URL https://api.github.com/users/janakaud/repos I receive a huge response (148 KB deflated):

[  
{  
"id": 129543465,  
"name": "apps-script-google-services",  
"full\_name": "janakaud/apps-script-google-services",  
"owner": {  
"login": "janakaud",  
"id": 5234574,  
"avatar\_url": "[https://avatars0.githubusercontent.com/u/5234574?v=4](https://avatars0.githubusercontent.com/u/5234574?v=4)",  
...  
},  
"private": false,  
"html\_url": "[https://github.com/janakaud/apps-script-google-services](https://github.com/janakaud/apps-script-google-services)",  
...  
},  
{  
"id": 129543325,  
"name": "apps-script-misc",  
"full\_name": "janakaud/apps-script-misc",  
...  
},  
{  
"id": 129543204,  
"name": "apps-script-monitoring",  
"full\_name": "janakaud/apps-script-monitoring",  
...  
},  
...  
]  

which contains a whole lot of fields that I am not interested in. I’m expecting to obtain a more compact, filtered response instead, such as:

[  
{"name": "apps-script-google-services"},  
{"name": "apps-script-misc"},  
{"name": "apps-script-monitoring"},  
...  
]  

or, even better:

[  
"apps-script-google-services",  
"apps-script-misc",  
"apps-script-monitoring",  
...  
]  

TIA :slight_smile:

Hi @janakaud,

THe v3 rest api does not provide this, but the v4 GraphQL api is a lot more flexible in this regard.

1 Like

@seveas thanks for the insight! Although it’s unfortunate (I have no way of migrating right now); I believe it being available in v4 means that it won’t become available in v3, even in the future