In the world of WCF and SOAP, if you want to consume a WCF service, you simply ask VS to add a service reference, direct it to the WSDL file, and it generates a client for you. Wouldn’t it be nice if you could do the same for a REST service!
It turns out that you can (although, admittedly, the process is not as seamless). The tool of choice for providing this WSDL emulation is called Swagger. This post isn’t about Swagger, and it assumes that you know your Swagger source. Azure has its own flavour of Swagger, called “Azure Swagger” (seriously). Consuming that is the main focus of this.
AutoRest is the client-side tool that allows you to automatically create proxy classes for your REST interactions, and is available via NuGet… but it doesn’t work at the time of writing this.
Instead, use Node Package Manager (NPM). First, install it, via this link.
Next, install AutoRest. Your friend here is the Package Manager Console:
npm install -g autorest
Update the version (this is, as I understand it, not strictly necassary, as it will install the latest version):
Finally, check the version that is installed (okay, clearly this isn’t necessary at all, but I like to check that the computer and me both have a synchronised view of events as often as possible):
Next, check where you are:
Then call AutoRest:
AutoRest -Input [SwaggerLocation] -Namespace [Namespace]
A note on Namespaces
It’s tempting to be dismissive of the namespace. Remember that, the namespace that you give will be assigned to classes and used by classes… so, if you were, for example, to give a namespace that matched the class name (so, for example, if you’re creating Recommendations, you’ll have a class called “Recommendations”) then you’ll find you’ll get thousands of strange errors that apparently make no sense. Think carefully about the namespace!
Where is the Swagger Location?
Obviously, the answer is, it depends… however; for Azure, most services have that readily available; let’s take Recommendations: