Acknowledgement: This is a cross-posting over Creating Service Contract with AutoRest, Swagger and HAL at Kloud blog.
According to Richardson Maturity Model, REST API level 3 should provide hypermedia within responses as metadata, so that users can easily navigate to other resources. This is particularly important if Microservices architecture (MSA) is considered for your service or application. Because MSA is a collection of small REST API services, each API server should provide complete set of documents or manuals for others to consume it properly. In order to provide document automation, Swagger is one of the best choices, and HAL, in order to provide hypermedia within the response, is also yet another option. Of course, consuming those REST API at client applications is also important. In this case, AutoRest can give great benefits for your development. In this post, I’ll discuss HAL, Swagger and AutoRest with some demo codes.
Demo codes can be found at:
- https://github.com/devkimchi/HAL-Swagger-Sample
- https://github.com/devkimchi/TypeScript-WebApi-Sample
Integrating HAL
HAL (Hypertext Application Language) has been suggested by Mike Kelly. Its formal specification can be found at this IETF draft. Generally speaking, many REST API services are well structured. They don’t just only return data in the response, but also include various metadata for reference purpose, in their own way. HAL offers a standardised way of including hyperlinks into those responses. Here’s an example
https://gist.github.com/justinyoo/833c78c436948493bf87#file-get-product-txt
If you send a request with the URL above, the expecting response will look like:
https://gist.github.com/justinyoo/833c78c436948493bf87#file-get-product-json
However, if HAL is applied, the response will look like:
https://gist.github.com/justinyoo/833c78c436948493bf87#file-get-product-hal-json
Let’s see another example returning a collection.
https://gist.github.com/justinyoo/833c78c436948493bf87#file-get-product-collection-txt
The request will expect reaponse like:
https://gist.github.com/justinyoo/833c78c436948493bf87#file-get-product-collection-json
If HAL is applied, the response will look like:
https://gist.github.com/justinyoo/833c78c436948493bf87#file-get-product-collection-hal-json
Can you see differences? HAL applied responses contain much richer data that can easily navigate to other resources.
OK, theory is done. Let’s implement HAL on your API. First of all, assuming you’ve got an existing Web API app containing models of Product and ProductCollection looking like:
https://gist.github.com/justinyoo/833c78c436948493bf87#file-product-product-collection-model-cs
There are many HAL implementations on our NuGet. For now, I’m going to use WebApi.Hal. Once installed, you can modify those models with this way, by minimising impacts on the existing application:
https://gist.github.com/justinyoo/833c78c436948493bf87#file-product-product-collection-model-hal-cs
Then, register HAL into your Global.asax.cs or Startup.cs:
https://gist.github.com/justinyoo/833c78c436948493bf87#file-hal-config-cs
That’s it! Too simple? Here’s the magic inside the Representation class. It has the public Links property that takes care of all hypertext links. All we need after the HAL implementation is to add appropriate links to each instance, manually or automatically. Here’s a way to include hyperlinks manually within a controller level:
https://gist.github.com/justinyoo/833c78c436948493bf87#file-product-api-controller-hal-cs
Once it’s done, build it and check the API response. Then you’ll see the result including those HAL links like above. Now, let’s move to the next part, Swagger.
Integrating Swagger
According to Swagger website, Swagger provides a standard, languae-independent interface to REST API so that both humans and computers can easily find and understand the API structure without reading source codes or documents. There are several other alternatives like RAML or API Blueprint, so it’s up to you which one shoul you choose.
Swashbuckle is one of C# implementations of Swagger. It’s easy to use and virtually zero configuration is required for the basic usage. Let’s install Swashbuckle into your project. Once installed, it also adds another file, SwaggerConfig.cs under the App_Start directory. You can directly use it or do some modification for your application. Let’s have a look.
https://gist.github.com/justinyoo/833c78c436948493bf87#file-swagger-config-before-cs
When you open SwaggerConfig.cs file, it looks like above. In order for you to have more control on it, comment out the first line, [assembly: ...] and make the Register() method to be an extension method:
https://gist.github.com/justinyoo/833c78c436948493bf87#file-swagger-config-after-cs
Then, put the following like into either your Global.asax.cs or Startup.cs for registration:
https://gist.github.com/justinyoo/833c78c436948493bf87#file-swagger-config-cs
That’s all. Build and run your app, type URL like http://my.api.service/swagger and you will see the Swagger UI screen like:
What you need to notice is the JSON schema URL in the picture above. When you type the URL from Postman, it will look like:
This is basically a JSON schema file and pretty much equivalent to WSDL from SOAP. With terms of WCF, it contains both service contract and data contract so, with this schema, your client applications can access to the API and consume it. There’s no obstacle for it.
So far, we’ve implemented both HAL and Swagger on your REST API server. How can we then consume those APIs on your clients like web app or mobile app? Let’s move onto the next section for this.
Deserialising Swagger JSON schema with AutoRest
Once Swagger JSON schema is generated, your client apps should be able to consume it with minised efforts. AutoRest can bring great benefits to your client apps. It automatically generates both service contracts and data contracts pointing to your REST APIs using Swagger JSON schema. Currently, AutoRest supports C#, Java, Node.js and Ruby and the number of languages gets gradually expanded.
Here’s an ASP.NET MVC app. Within the app, assuming there’s a folder, Proxies. Swagger JSON schema file is then placed into that folder with name of swagger.json. Then install AutoRest CLI app and runtime library from NuGet. In order to auto-generate client libraries, try the following command on your Command Prompt:
https://gist.github.com/justinyoo/833c78c436948493bf87#file-build-bat
What does the command line mean? Here’s the brief explanation:
- Run AutoRest.exe
- Input JSON schema name is
swagger.json - The namespace for auto-generated files is
HalSwaggerSample.WebApp.Proxies - Store auto-generated files into
Proxies - Set output file type as C#
After the generation, you will be able to see bunch of files have been stored into the Proxies folder. The most important file is HalSwaggerSampleHalApiApp.cs. Of course, the file name (or class name) will be different from yours. It provides the service endpoint and service contract information. It also contains the corresponding interface, IHalSwaggerSampleHalApiApp, so this service contract is testable, mockable and injectable. Therefore, your controller/action can be written like:
https://gist.github.com/justinyoo/833c78c436948493bf87#file-product-mvc-controller-cs
Therefore, the result screen will look like:
Did you find that can’t be easier?
We’ve so far had a look at HAL, Swagger and AutoRest. Both HAL and Swagger are to design your REST API to be more discoverable, readable and maintainable and make client apps build their access point much easier with tools like AutoRest. How about implementing those into your Web API, if you’re considering MSA? It’s all yours.