What to do with URL fields

[phadej]

Just text? verify or not?

[Hrothen]

You mean the URLs in the JSON payloads? Most(all?) of them correspond to other api calls, so maybe provide an action that executes the associated function with those fields filled in?

[phadej]

@Hrothen Yes and no, there are URLs to other endpoints, it might make sense to try to turn those fields into something one could construct GitHub.Request, but there are cases like

"events_url": "https://api.github.com/users/octocat/events{/privacy}",

OTOH, there are non-json payloads like

"html_url": "https://github.com/octocat/Hello-World/issues/1347",

which might be useful (especially avatar), it would be nice to have something so one doesn't need to handle error case in parseRequest.

[phadej]

... that said, I'll probably do nothing for 0.15 with this issue

[Hrothen]

The first example is an endpoint, albeit one not yet implemented in this library :) Unless you'd want the public and private user events endpoints to be different functions rather than taking an argument to specify.

It seems better to provide Text url fields than none at all, but I guess if you later wanted to provide functions there, it would be a pain for people to upgrade.

[phadej]

the url fields are parsed into newtype URL = URL Text in master like in http://docs.futurice.com/haskell-mega-repo/github-0.15.0/GitHub-Data-PullRequests.html (not all though, have to go thru) and to Text in Hackage's 0.14. This issue is what to do with the URL type. Parse it further to more elaborated type or not...

[Hrothen]

Oh man, somehow I missed that.