{
  "$type": "site.standard.document",
  "canonicalUrl": "https://johnnyreilly.com/posts/azure-devops-node-api-git-api-getrefs-wiki-api",
  "description": "The Azure DevOps Node.js client library has limitations and missing features. Workarounds are possible for using Azure DevOps REST API directly.",
  "path": "/posts/azure-devops-node-api-git-api-getrefs-wiki-api",
  "publishedAt": "2020-10-31T00:00:00.000Z",
  "site": "at://did:plc:yy3apqjlms24kso7ahn7lbmb/site.standard.publication/3mova7c4nho2b",
  "tags": [
    "node.js",
    "azure devops"
  ],
  "textContent": "The Azure DevOps Client library for Node.js has limitations and missing features, IGitApi.getRefs is missing pagination and IWikiApi is missing page create or update. This post details some of these issues and illustrates a workaround using the Azure DevOps REST API.\n\n\n\nThe Azure DevOps REST API and Client Libraries\n\nI've been taking a good look at the REST API for Azure DevOps. I'm delighted to say that it's a very full API. However, there's quirks.\n\nI'm writing a tool that interrogates Azure DevOps in order that it can construct release documentation. That release documentation we would like to publish to the project wiki.\n\nTo make integration with Azure DevOps even easier, the ADO team have put a good amount of work into client libraries that allow you to code in your language of choice. In my case I'm writing a Node.js tool (using TypeScript) and happily the client lib for Node is written and published with TypeScript too. Tremendous! However, there is a \"but\" coming....\n\nGitApi and WikiApi shortcomings\n\nAs I've been using the Node client lib, I've found minor quirks. Such as the GitApi.getRefs missing the pagination parts of the API.\n\nWhilst the GitApi was missing some parameters on a method, the WikiApi was missing whole endpoints, such as the Pages - Create Or Update one. The various client libraries are auto-generated which makes contribution a difficult game. The lovely Matt Cooper has alerted the team\n\n> These clients are generated from the server-side controllers, and at a glance, I don't understand why those two parameters weren't included. Full transparency, we don't dedicate a lot of cycles here, but I will get it on the team's radar to investigate/improve.\n\nIn the meantime, I still had a tool to write.\n\nHandrolled Wiki API\n\nWhilst the Node.js client lib was missing some crucial pieces, there did seem to be a way forward. Using the API directly; not using the client lib to do our HTTP and using axios instead. Happily the types we needed were still available for be leveraged.\n\nLooking at the docs it seemed it ought to be simple:\n\nhttps://docs.microsoft.com/en-us/rest/api/azure/devops/?view=azure-devops-rest-6.1#assemble-the-request\n\nBut when I attempted this I found my requests erroring out with 203 Non-Authoritative Informations. It didn't make sense. I couldn't get a single request to be successful, they all failed. It occurred to me that the answer was hiding in node_modules. I'd managed to make successful requests to the API using the client lib. What was it doing that I wasn't?\n\nThe answer ended up being an authorization one-liner:\n\nWith this in hand everything started to work and I found myself able to write my own clients to fill in the missing pieces from the client lib:\n\nWith this I was able to write code like this:\n\nand the wikis were ours!\n\nHandrolled Git API\n\nSimilarly it's possible to write a client for the Git API that reuses the types from the client lib.\n\nConclusion\n\nThe client lib is great, but it's not perfect. It's missing some APIs and it's missing some features. But as we can see, it's possible to work around the shortcomings and write our own clients to fill in the gaps.",
  "title": "Azure DevOps Client for Node.js - GitApi / WikiApi limitations"
}