The art of simplicity

This week I had the honor to give a training to some of the newly started young professionals in our organisation. The topic of the training was API design in ASP.NET Core. During this training we discussed multiple topics and a lot of interesting questions were raised. I'll try to tackle some of them with a blog post. The question I try to tackle today is... What is idempotent in REST? An important aspect when building REST API’s is the concept of ‘idempotency’. ‘Idem…what?’ I here you thinking. Let’s ask MDN for an explanation: An HTTP method is idempotent if an identical request can be made once or several times in a row with the same effect while leaving the server in the same state. In other words, an idempotent method should not have any side effects — unless those side effects are also idempotent. Implemented correctly, the GET , HEAD , PUT , and DELETE methods are idempotent , but not the POST method. All safe methods are also idempotent. That explanation b

This week I had the honor to give a training to some of the newly started young professionals in our organisation. The topic of the training was API design in ASP.NET Core. During this training we discussed multiple topics and a lot of interesting questions were raised. I'll try to tackle some of them with a blog post. The question I try to tackle today is... What does the [APIController] attribute do? If you created your first Web API in ASP.NET Core (through dotnet new webapi -o MyFirstAPI ), you ended up with a WeatherForecastController containing the following code: On top of this controller class, you see above the Route attribute, the ApiController attribute. Adding this attribute on top of your controller has a bigger impact than you would think and enables the following behaviours: Attribute routing requirement Automatic HTTP 400 responses Binding source parameter inference Multipart/form-data request inference Problem details for error stat

This week I had the honor to give a training to some of the newly started young professionals in our organisation. The topic of the training was API design in ASP.NET Core. During this training we discussed multiple topics and a lot of interesting questions were raised. I'll try to tackle some of them with a blog post. The question I try to tackle today is... When do I know that my Web API is truly RESTful? Yesterday I introduced the concept of REST and mentioned that it was an architecture style. As a result you’ll find a lot of different flavors of Web API’s in the wild each using a different approach and all calling themselves REST API’s. To help you answer the question above, we can use the Richardson Maturity Model . Leonard Richardson analyzed a hundred different web service designs and divided these designs into four categories . These categories are based on how much the web services are REST compliant . He used three main factors to decide the maturity of a

Today I had the honor to give a training to some of the newly started young professionals in our organisation. The topic of the training was API design in ASP.NET Core. During this training we discussed multiple topics and a lot of interesting questions were raised. I'll try to tackle some of them with a blog post. Let's start with a first question and immediatelly a controversial one... What is REST? Let's first have a look at what Wikipedia has to say about REST: Representational state transfer ( REST ) is a software architectural style that describes a uniform interface between physically separate components, often across the Internet in a Client-Server architecture. It was originally introduced in a dissertation by Roy Fielding titled 'Architectural Styles and the Design of Network-based Software Architectures’. Here is the link if you like to read it: https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm . What is most important to understand is

When trying to build a .NET application on our build server, it failed with the following error message: ##[error]C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(3326,5): Error MSB3326: Cannot import the following key file: . The key file may be password protected. To correct this, try to import the certificate again or import the certificate manually into the current user’s personal certificate store. C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(3326,5): error MSB3326: Cannot import the following key file: . The key file may be password protected. To correct this, try to import the certificate again or import the certificate manually into the current user’s personal certificate store. [D:\b\3\_work\32\s\Source\Example.csproj] ##[error]C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\MSBuild\Current\Bin\Microsoft.C

When trying to deploy a pod on our AKS cluster, it hanged in the pending state. I looked at the logs and noticed the following warning: FailedScheduling – 1 node(s) had volume node affinity conflict The pod I tried to deploy had a persistent volume claim and I was certain that the persistent volume was succesfully deployed and available. What was going wrong? It turned out that my AKS cluster was deployed in 3 availability zones but I had only 2 nodes running: AKS cluster is gedeployed in 3 zones maar er zijn maar 2 nodes: $ kubectl describe nodes | grep -e "Name:" -e "failure-domain.beta.kubernetes.io/zone" Name:               aks-agentpool-38609413-vmss000003                     failure-domain.beta.kubernetes.io/zone= westeurope-1 Name:               aks-agentpool-38609413-vmss000004                     failure-domain.beta.kubernetes.io/zone= westeurope-2 Here we can see that our nodes are living in zones westeurope-1 and westeuro