External raw calls

[kubaPod]

What if the API gateway, e.g. GitHub does not support a specific method due to whatever reason? Is there a natural way to make that call anyway? If not, there should be :)

If there is no general way, it should be mentioned what internal functions can be used to assemble the call.

With respect to GitHub only authorization patch is needed and I guess many will be fine with writting HTTPRequest by themselves.

[b3m2a1]

There is. I'll add a GitHub specific example page to the wiki to document some of the things you can do with it.

[b3m2a1]

@kubaPod See here. The example posted there should work in the most recent version of BTools, but passing the return type as the final string for raw requests won't work before that.

[kubaPod]

@b3m2a1 I really tried to make that work for create release and upload asset but I ended up with:

BTools`External`Git`GitHubCreateRelease[  "kubapod/devtools"
, "v0.8.0"
, "Name" -> "VerificationTest template"
]

BTools`External`Git`GitHubUploadReleaseAsset[  "kubapod/devtools"
, (*id*)
, (*path to .paclet*)
]

Can you tell me what would be the way to go with GitHub?

I tried to put tag_name and name as params, but I suppose they should go to the body. But the main problem is that authorization headers are not merged correctly when POST method is used and the call returns 404 (which does not help finding out the cause).

Side question is why it should be TagName rather than tag_name mentioned in api spec. I tried with both so it is an offtopic question but appreciate clarification.

Best

[b3m2a1]

@kubaPod I added an example usage for it coming out of GitHub. I'm surprised it wasn't working for you. If it continues not to work I'd like to know whatever you can tell me about it so I can try to fix it. I also added a note or two on using the "Authorization" header so that it's easier for to use in the raw calls. I chose to use names that were more in line with the way Mathematica names its options, although I was tempted to just use the built-in names. I did this originally for Git and just kept the trend for GitHub as well.

[kubaPod]

@b3m2a1 Thanks. I interpreted: GitHub[ {path...}, {params...}, <|headers...|>, ops... ] as:

GitHub[
  {repos, kubapod, devtools, releases},
  { TagName -> v0.8.0, Name -> whatever},
  <|"Method" -> "POST"|>
]

[b3m2a1]

@kubaPod Ah I see. I didn't realize you were trying to run it via the raw interface. If that's the case you'll need to use "tag_name"->..., etc., although for most of these GitHub API calls you need to put the parameters in the "Body" of the request as JSON (I guess it's not quite right to call them headers in that case...). I do a filtering and renaming of the passed Options in my functions before exporting them to the "Body".

[kubaPod]

@b3m2a1 so what would be the corrected version of my code?

[b3m2a1]

@kubaPod this kind of thing works:

GitHub[
 {"repos", "b3m2a1", "test", "releases"},
 <|
  "Method" -> "Post",
  "Body" ->
   ExportString[{"tag_name" -> "v0.0.1", "name" -> "test"}, "JSON"],
  "Headers" ->
   {"Authorization" -> Automatic}
  |>,
 "ResultObject"
 ]

[kubaPod]

I think this can be closed as soon as that example shows next to Direct API Access in GitHub wiki page.