I don’t like when someone is removing nice features in hardware I bought. And this is the exactly situation my father had with Pioneer VSX-528 amplifier, after two years of using it with Spotify Connect the feature has been disabled permamently without any explanation. It was nice feature and was used frequentely, so I decieded to make something with it. To make it working as original feature I had to hack the amplifier a little bit ;)

Building a software that is HATEOAS enabled is a challenging task. There is limited number of frameworks/libraries that supports the fight. Additionally, good design of our domain should be even better - to build relevant link we need to introspect the state of the domain and the context of request. And this is just the tip of an iceberg.

In this part of the series I’ll be talking about links - how do we know how link should look like? How do we even know how our application is visible to the world?

In previous post I’ve described how HATEOAS works from the theoretical point of view. In this post I’ll show you very naïve implementation in ASP.NET WebAPI2.

In a couple of my previous projects, I was on the way to make true REST API. By “true REST” (irony assumed) I mean REST on the third level of Richardson Maturity Model. After those projects, I’m amazed by idea of HATEOAS (even if resulting API is not the REST at all).

Since I wrote the post about CQRS I was asked couple times how to use presented QueryDispatcher and why its usage is so ugly. In the moment I was writing that post, my idea was to show the simplest implementation of a complex idea. Hoped to make simple, yet working implementation. I wanted to make it a good example how to start, but without adding non-essential complexity to the problem discussed. I’ve never assumed that this will be production ready solution (actually it might be ;). In this post I’ll try to show the better implementation of QueryDispatcher that is easier to use in our code.